Method and system for recovering damaged TBI backup mirror image

Abstract

The invention discloses a recovery method and system for a damaged TBI backup mirror image. The method comprises the steps that the file size and the mirror image reading offset of a TBI backup mirror image file are obtained; in response to the fact that the mirror image reading offset is smaller than the file size, reading preset byte data from a file header, sequentially judging whether the preset byte data meets the requirements of the equipment information storage block, whether the head of the mirror image is ended, whether the preset byte data reaches a partition storage starting position, whether the preset byte data reaches a partition tail and whether the preset byte data is a partition tail information storage position identifier; in the judgment process, the reading offset is adjusted according to different judgment results, and data reading and analysis operation is carried out according to the data type; and continuing the operations of judgment, offset adjustment, data reading and analysis until the reading of the mirror image file is completed. According to the method, the storage format of the damaged TBI file can be automatically analyzed, the storage position of the partition data can be positioned, the storage format can be analyzed, and the backup partition data in the TBI mirror image file with the damaged head can be recovered.

Description

Technical Field

[0001] The present invention relates to the technical field of data recovery, and in particular to a method and system for recovering a damaged TBI backup image. Background Art

[0002] In today's digital age, data backup and recovery are crucial for both enterprises and individual users. As a powerful and flexible disk image file format developed by TeraByte Unlimited, TBI (TeraByte Image) image provides users with efficient and reliable data backup and recovery solutions. It can completely copy the contents of the disk, including the operating system, applications, data files, and disk partition structure. This allows the disk to be quickly restored to its previous state through TBI image in the face of data loss or system failure, greatly reducing the time and workload of data recovery, improving work efficiency, and ensuring business continuity.

[0003] At present, the data recovery methods for TBI images on the market mainly focus on parsing the complete TBI file, or restoring, viewing and mounting the complete TBI image based on the TeraByte Drive Image software under Windows. However, in actual application scenarios, the TBI file header is often damaged. For example, physical damage to the storage medium, virus attacks, unexpected power outages, etc. may cause the loss or destruction of part of the file header data. Once the file header is damaged, the existing conventional recovery software often cannot normally restore and load the image file, because they usually rely on complete header information to parse and process the image data. Header damage makes it impossible for the software to accurately identify the image file format, partition structure and other key information, resulting in data cannot be recovered, which brings huge data loss risks to users. This situation highlights the urgency and importance of research on TBI image file recovery methods for damaged headers, in order to fill the deficiencies of existing technologies in this regard and meet the data recovery needs of users when facing such problems. Summary of the invention

[0004] In order to solve the above technical problems existing in the prior art, the present invention proposes a method and system for recovering a damaged TBI backup image to solve the above technical problems.

[0005] According to a first aspect of the present invention, a method for recovering a damaged TBI backup image is proposed, comprising:

[0006] S1: Get the file size and image read offset of the TBI backup image file;

[0007] S2: In response to the image read offset being less than the file size, read preset byte data from the file header, and sequentially determine whether the preset byte data meets the device information storage block requirement, whether the image header ends, whether the partition storage start position is reached, whether the partition tail is reached, and whether the data is a partition tail information storage position identifier;

[0008] S3: In the judgment process of S2, the read offset is adjusted according to different judgment results, and at the same time, data reading and parsing operations are performed according to the data type, including parsing special block data and common block data;

[0009] S4: Continue the above-mentioned determination, offset adjustment, data reading and analysis operations until the image file reading is completed.

[0010] In some specific embodiments, the preset byte data is 12 bytes of data read from the file header.

[0011] In some specific embodiments, determining in S2 whether the preset byte data meets the requirements of the device information storage block is specifically determining whether the read preset byte data is 0x01, and the block length is 0x198 of the device information storage block. If so, the file offset is adjusted according to the storage structure of the 0x01 block of the image header storage structure partition, the file offset is increased by 12 bytes, and then 0x198 bytes are added on this basis, and the relationship between the image read offset and the file size is re-determined; if not, a determination is made as to whether the image header ends.

[0012] In some specific embodiments, the judgment of whether the image header ends is specifically to determine whether the preset byte data is 0xFFFFFFFF000000000FFFFFFFF. If so, the file offset is increased by 1 byte, and the relationship between the image read offset and the file size is re-determined; if not, the file offset is increased by 0x0C bytes to determine whether the partition storage start position is reached.

[0013] In some specific embodiments, determining whether the partition storage start position has been reached is specifically to read 8 bytes of data from the current file position and store them in the space pointed to by the buffer pointer pBuf, analyze the data in pBuf, and determine whether the partition storage start position has been reached. If so, the file offset is increased by 16 bytes to determine whether the partition end has been reached. If not, the file offset is increased by 1 byte to re-determine the relationship between the image read offset and the file size.

[0014] In some specific embodiments, the judgment of whether the end of the partition has been reached is specifically to read 8 bytes of data from the current file position and store them into the space pointed to by the buffer pointer pBuf, analyze the data in pBuf to determine whether it indicates that the end of the partition has been reached, if so, increase the file offset by 8 bytes, obtain the low 16 bits of data in pBuf through the pBuf&0x0000FFFF operation and convert it into an integer and add it to the file offset, read 8 bytes of data from the new offset position into the buffer again, extract the low 16 bits of data in pBuf again, convert it into an integer and add it to the file offset, and judge the storage location identifier of the partition tail information.

[0015] In some specific embodiments, if the end of the partition is not reached, it is further determined whether the read data is special block data. If it is special block data, the file offset is increased by 8 bytes, 0x0C bytes of data are read from the current offset position, and these data are parsed according to the special block structure to obtain the offset position information of the next data block. After obtaining the offset position, the offset is added to the file offset so that the offset points to the new position. After completing the processing of the special block data, it is continued to determine whether the image file is read; if it is not special block data, the file offset is increased by 8 bytes, the lower 16 bits of data in pBuf are extracted and converted into an integer and added to the file offset so that the offset points to the starting position of the next data block. After completing data parsing and offset adjustment, the image file reading continues.

[0016] In some specific embodiments, the judgment of the partition tail information storage location identifier specifically includes obtaining whether the partition tail information storage location identifier is contained in the current data. If it is contained, based on the partition tail information storage structure obtained in advance by analysis, the lower 16 bits of data in pBuf are converted into an integer value to determine the file read offset position, and the integer value is added to the file offset to continue to judge whether the subsequent data still has partition tail information or whether the partition data part has been processed; if it is not contained, the file read offset is increased by 8 bytes, and the judgment and processing of the partition tail information continues.

[0017] According to a second aspect of the present invention, a computer-readable storage medium is provided, on which one or more computer programs are stored. When the one or more computer programs are executed by a computer processor, the above method is implemented.

[0018] According to a third aspect of the present invention, a recovery system for a damaged TBI backup image is provided, comprising:

[0019] A data acquisition unit configured to acquire a file size and an image reading offset of a TBI backup image file;

[0020] a judgment unit configured to read preset byte data from the file header in response to the image read offset being less than the file size, and to sequentially judge whether the preset byte data meets the device information storage block requirement, whether the image header ends, whether the partition storage start position is reached, whether the partition tail is reached, and whether the data is a partition tail information storage position identifier;

[0021] The adjustment and parsing unit is configured to adjust the read offset according to different judgment results during the judgment process of the judgment unit, and at the same time, perform data reading and parsing operations according to the data type, including parsing SpecialBlock data and Block data;

[0022] The recovery control unit is configured to continue the above-mentioned determination, offset adjustment, data reading and parsing operations until the image file reading is completed.

[0023] In some specific embodiments, the preset byte data is 12 bytes of data read from the file header.

[0024] In some specific embodiments, the judging unit specifically includes:

[0025] Determine whether the preset byte data meets the requirements of the device information storage block: Determine whether the preset byte data read is 0x01, and the device information storage block with a block length of 0x198. If so, adjust the file offset according to the storage structure of the 0x01 block of the image header storage structure partition, increase the file offset by 12 bytes, and then increase 0x198 bytes on this basis, and re-determine the relationship between the image read offset and the file size; if not, determine whether the image header ends;

[0026] Determine whether the image header ends: Determine whether the preset byte data is 0xFFFFFFFF000000000FFFFFFFF. If so, increase the file offset by 1 byte and re-determine the relationship between the image read offset and the file size; if not, increase the file offset by 0x0C bytes to determine whether the partition storage start position has been reached;

[0027] Determine whether the partition storage start position has been reached: read 8 bytes of data from the current file position and store them in the space pointed to by the buffer pointer pBuf, analyze the data in pBuf, and determine whether the partition storage start position has been reached. If so, increase the file offset by 16 bytes to determine whether the partition end has been reached. If not, increase the file offset by 1 byte to re-determine the relationship between the image read offset and the file size.

[0028] Determine whether the partition tail has been reached: read 8 bytes of data from the current file position and store them in the space pointed to by the buffer pointer pBuf, analyze the data in pBuf to determine whether it indicates that the partition tail has been reached. If so, increase the file offset by 8 bytes, obtain the lower 16 bits of data in pBuf through the pBuf&0x0000FFFF operation, convert it into an integer, and add it to the file offset, read 8 bytes of data from the new offset position to the buffer again, extract the lower 16 bits of data in pBuf again, convert it into an integer, and add it to the file offset to determine the storage location identifier of the partition tail information;

[0029] Determine the partition tail information storage location identifier: obtain whether the partition tail information storage location identifier is contained in the current data. If it is contained, according to the partition tail information storage structure obtained in advance, use the low 16-bit data in pBuf to convert it into an integer value to determine the file read offset position, add the integer value to the file offset, and continue to determine whether the subsequent data still has partition tail information or whether the partition data part has been processed; if it is not contained, increase the file read offset by 8 bytes and continue to determine and process the partition tail information.

[0030] In some specific embodiments, if the end of the partition is not reached, it is further determined whether the read data is special block data. If it is special block data, the file offset is increased by 8 bytes, 0x0C bytes of data are read from the current offset position, and these data are parsed according to the special block structure to obtain the offset position information of the next data block. After obtaining the offset position, the offset is added to the file offset so that the offset points to the new position. After completing the processing of the special block data, it is continued to determine whether the image file is read; if it is not special block data, the file offset is increased by 8 bytes, the lower 16 bits of data in pBuf are extracted and converted into an integer and added to the file offset so that the offset points to the starting position of the next data block. After completing data parsing and offset adjustment, the image file reading continues.

[0031] The present invention proposes a method and system for recovering a damaged TBI backup image. For a TBI image file with damaged header, by deeply analyzing its storage format, it is possible to accurately locate the partition data storage location, effectively parse the storage format, and successfully recover the backup partition data. In actual scenarios, the problem that the file header is damaged and cannot be processed by conventional recovery software is solved, the success rate of data recovery is greatly improved, the loss caused by data loss is reduced, and a reliable data recovery solution is provided for users. It has important practical application value, effectively guarantees the security and availability of data, fills the gap in the prior art in the recovery of TBI images with damaged headers, and promotes the development of data recovery technology in related fields. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated into and constitute a part of this specification. The accompanying drawings illustrate the embodiments and together with the description are used to explain the principles of the present invention. Other embodiments and many expected advantages of the embodiments will be readily appreciated as they become better understood by reference to the following detailed description. Other features, objects and advantages of the present application will become more apparent by reading the detailed description of the non-limiting embodiments made with reference to the following drawings:

[0033] Figure 1 is a flow chart of a method for recovering a damaged TBI backup image according to an embodiment of the present application;

[0034] Figure 2 It is a schematic diagram of the storage structure of a TBI image file of a specific embodiment of the present application;

[0035] Figure 3 It is a schematic diagram of the storage structure of the mirror image header of a specific embodiment of the present application;

[0036] Figure 4 It is a schematic diagram of the storage structure of partition data of a specific embodiment of the present application;

[0037] Figure 5 It is a schematic diagram of the storage structure of a partition tail information block of a specific embodiment of the present application;

[0038] Figure 6 It is a flowchart of a method for recovering a damaged TBI backup image according to a specific embodiment of the present application;

[0039] Figure 7 is an architecture diagram of a recovery system for a damaged TBI backup image according to an embodiment of the present application;

[0040] Figure 8 is a schematic diagram of experimental results of an embodiment of the present application;

[0041] Fig. 9 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application. DETAILED DESCRIPTION

[0042] The present application will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It should also be noted that, for ease of description, only the parts related to the relevant invention are shown in the accompanying drawings.

[0043] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0044] Figure 1 A flowchart of a method for recovering a damaged TBI backup image according to an embodiment of the present application is shown. Figure 1 As shown, the method comprises the following steps:

[0045] S101: Obtain the file size and image reading offset of the TBI backup image file.

[0046] S102: In response to the mirror read offset being less than the file size, read preset byte data from the file header, and determine in turn whether the preset byte data meets the device information storage block requirements, whether the mirror header ends, whether the partition storage start position is reached, whether the partition tail is reached, and whether the data is a partition tail information storage position identifier.

[0047] S103: During the judgment process of S102, the read offset is adjusted according to different judgment results. At the same time, data reading and parsing operations are performed according to the data type, including parsing special block data and common block data.

[0048] S104: Continue the above-mentioned determination, offset adjustment, data reading and analysis operations until the image file reading is completed.

[0049] In a specific embodiment, the preset byte data is 12 bytes of data read from the file header. Determining whether the preset byte data meets the device information storage block requirements is specifically to determine whether the read preset byte data is 0x01 and the device information storage block with a block length of 0x198. If so, the file offset is adjusted according to the storage structure of the 0x01 block of the image header storage structure partition, the file offset is increased by 12 bytes, and then 0x198 bytes are added on this basis to re-determine the relationship between the image read offset and the file size; if not, a determination is made as to whether the image header ends.

[0050] In a specific embodiment, the judgment of whether the image header ends is specifically to determine whether the preset byte data is 0xFFFFFFFF000000000FFFFFFFF. If so, the file offset is increased by 1 byte, and the relationship between the image read offset and the file size is re-determined; if not, the file offset is increased by 0x0C bytes to determine whether the partition storage start position is reached.

[0051] In a specific embodiment, determining whether the partition storage start position has been reached is specifically to read 8 bytes of data from the current file position and store them in the space pointed to by the buffer pointer pBuf, analyze the data in pBuf, determine whether the partition storage start position has been reached, if so, increase the file offset by 16 bytes, and determine whether the partition end has been reached, if not, increase the file offset by 1 byte, and re-determine the relationship between the image read offset and the file size.

[0052] In a specific embodiment, the judgment of whether the end of the partition has been reached is specifically to read 8 bytes of data from the current file position and store them into the space pointed to by the buffer pointer pBuf, analyze the data in pBuf, and judge whether it indicates that the end of the partition has been reached. If so, the file offset is increased by 8 bytes, and the lower 16 bits of data in pBuf are obtained through the pBuf&0x0000FFFF operation and converted into an integer and added to the file offset, and 8 bytes of data are read from the new offset position into the buffer again, and the lower 16 bits of data in pBuf are extracted again, converted into an integer and added to the file offset, and the storage location identifier of the partition tail information is judged.

[0053] In a specific embodiment, if the end of the partition is not reached, it is further determined whether the read data is special block data. If it is special block data, the file offset is increased by 8 bytes, 0x0C bytes of data are read from the current offset position, and these data are parsed according to the special block structure to obtain the offset position information of the next data block. After obtaining the offset position, the offset is added to the file offset so that the offset points to the new position. After completing the processing of the special block data, it is continued to determine whether the image file is read; if it is not special block data, the file offset is increased by 8 bytes, the lower 16 bits of data in pBuf are extracted and converted into an integer and added to the file offset so that the offset points to the starting position of the next data block. After completing data parsing and offset adjustment, the image file reading continues.

[0054] In some specific embodiments, the judgment of the partition tail information storage location identifier specifically includes obtaining whether the partition tail information storage location identifier is contained in the current data. If it is contained, based on the partition tail information storage structure obtained in advance by analysis, the lower 16 bits of data in pBuf are converted into an integer value to determine the file read offset position, and the integer value is added to the file offset to continue to judge whether the subsequent data still has partition tail information or whether the partition data part has been processed; if it is not contained, the file read offset is increased by 8 bytes, and the judgment and processing of the partition tail information continues.

[0055] Figure 2 A schematic diagram of the storage structure of a TBI image file of a specific embodiment of the present application is shown as follows: Figure 2 As shown in the figure, the storage structure of the TBI image file is divided into the image header + partition data + image tail. The image header mainly stores the image file identifier, the storage location in the image, the MBR data of the disk, and some storage information of the file partition in the source disk. The specific storage structure is as follows Figure 3 The storage structure diagram of the image header of a specific embodiment of the present application is shown in FIG. The partition data is stored or compressed in the image file in the data block format of 0x10000, and each data block is composed of an 8-byte block header + block data. The specific storage structure is as follows: Figure 4 The partition tail information block is stored at the end position of the partition data backup. The specific storage position in the TBI image file can be obtained by parsing the 0x01 block with a length of 0x198 in the TBI file header. It mainly stores the mapping relationship between each backup block of the partition data in the TBI image file and the number of partition backup blocks on the disk. The specific storage structure is as follows Figure 5 A schematic diagram of the storage structure of a partition tail information block of a specific embodiment of the present application.

[0056] The recovery principle of the above method is: for complete image data, by parsing the storage structure analyzed above, the partition data of the disk can be completely restored, but for the recovery of the image file with damaged header, due to the incomplete image header, the partition data cannot be obtained normally by parsing the file format. For the damage of part of the image header data, the location of the data block of the 0x01 block of 0x198 can be scanned and located during parsing. After traversing and parsing the 0x01 block, the end position of the image header storage of the file can be determined, and then the scan is started from the end position to determine the start position of the partition data, and then according to the storage structure of the Block analyzed above, the index value of a partition is scanned to determine the storage position of the tail of the partition, and the key-value pair information of the storage position of the partition backup block and the storage position relative to the disk is obtained, parsed and stored in the container, and then the container and the previous index file are traversed to parse the corresponding partition data.

[0057] Continue to refer Figure 6 , Figure 6 FIG. 1 is a flowchart of a method for recovering a damaged TBI backup image according to a specific embodiment of the present application. Figure 6 As shown, the method comprises the following steps:

[0058] Step #1: Get started;

[0059] Step #2: Get the TBI backup image file size i64ImageFileSize, image read offset i64Offset, and jump to step #3;

[0060] Step #3: Determine the relationship between i64Offset and i64ImageFileSize. If i64Offset>=i64ImageFileSize, the recovery is complete and jump to step #26; otherwise, jump to step #4;

[0061] Step #4: Read 12 bytes of data starting from the file header and jump to step #5;

[0062] Step #5: Determine whether the read data is 0x01 and the device information storage block with a block length of 0x198. If yes, jump to step #6; if not, jump to step #7;

[0063] Step #6: According to the storage structure of the 0x01 block of the image header storage structure partition, the file offset i64Offset+=12, i64Offset+=0x198, jump to step #3;

[0064] Step #7: Determine whether the image header ends, that is, whether pBuf is 0xFFFFFFFF00000000FFFFFFFF. If not, jump to step #8; if yes, jump to step #9;

[0065] Step #8: i64Offset += 1; Jump to step #3;

[0066] Step #9: i64Offset += 0x0C, jump to step #10;

[0067] Step #10: Read 8 bytes of data pBuf, jump to step #11;

[0068] Step #11: Determine whether the file offset data reaches the partition storage start position. If not, jump to step 12; if not, jump to step #13;

[0069] Step #12: i64Offset += 1, jump to step #10;

[0070] Step #13: i64Offset += 16, jump to step #14;

[0071] Step #14: Read 8 bytes of data pBuf, jump to step #15;

[0072] Step #15: Determine whether the data reaches the end of the partition. If yes, jump to step 16; if no, jump to step #22;

[0073] Step #16: i64Offset+=8, i64Offset+=(*(int*)(pBuf&0x0000FFFF)), jump to step #17;

[0074] Step #17: Read 8 bytes, i64Offset += (*(int*)(pBuf&0x0000FFFF)), jump to step #18;

[0075] Step #18: Get whether the current data is the storage location of the partition tail information, mark it, and jump to step #19;

[0076] Step #19: If bPartInfoEnd is true, jump to step #20; if not, jump to step #21;

[0077] Step #20: According to the partition tail information storage structure analyzed above, determine the file read offset position, i64Offset+=(*(int*)(pBuf&0x0000FFFF)), jump to step #21;

[0078] Step #21: i64Offset += 8, jump to step #3;

[0079] Step #22: Determine whether it is special block data, if yes, jump to step #23; if no, jump to step #24;

[0080] Step #23: According to the special block structure above, parse the SpecialBlock data, i64Offset+=8, read 0x0C data, and parse the offset position of the next Block, i64Offset+=0x0C;

[0081] Step #24: According to the above database structure, parse the Block data, i64Offset+=8, i64Offset+=(*(int*)(pBuf&0x0000FFFF)), jump to step #25;

[0082] Step #25: Determine whether the image file has been read. If not, jump to step #14. If yes, jump to step #26.

[0083] Step #26: Restoration complete.

[0084] Figure 7 A system architecture diagram for recovering a damaged TBI backup image according to an embodiment of the present application is shown, such as Figure 7The system includes a data acquisition 701, a judgment unit 702, an adjustment and analysis unit 703, and a recovery control unit 704, wherein the data acquisition unit 701 is configured to obtain the file size and the image reading offset of the TBI backup image file; the judgment unit 702 is configured to read preset byte data from the file header in response to the image reading offset being smaller than the file size, and to sequentially judge whether the preset byte data meets the device information storage block requirements, whether the image header ends, whether it reaches the partition storage start position, whether it reaches the partition tail, and whether the data is a partition tail information storage position identifier; the adjustment and analysis unit 703 is configured to adjust the read offset according to different judgment results during the judgment process of the judgment unit, and at the same time, perform data reading and analysis operations according to the data type, including parsing SpecialBlock data and Block data; the recovery control unit 704 is configured to continuously perform the above-mentioned judgment, offset adjustment, data reading and analysis operations until the image file reading is completed.

[0085] Figure 8 Schematic diagram of experimental results of an embodiment of the present application. Figure 8 As shown in the figure, the experimental result diagram verifies the effectiveness of the proposed damaged TBI backup image recovery method from multiple aspects such as file system structure, file integrity, and file attribute recovery by displaying the detailed properties of multiple files in the TBI image file. It shows that this method can accurately recover various information in TBI image files with damaged headers, making the restored file system as close to the original state as possible in logic and structure.

[0086] Reference below Fig. 9 It shows a schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application. Fig. 9 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0087] like Fig. 9 900. As shown in FIG. 1 , the computer system includes a central processing unit (CPU) 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. In the RAM 903, various programs and data required for the operation of the system 900 are also stored. The CPU 901, the ROM 902, and the RAM 903 are connected to each other via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0088] The following components are connected to the I / O interface 905: an input section 906 including a keyboard, a mouse, etc.; an output section 907 including a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, a modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I / O interface 905 as needed. A removable medium 911, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 910 as needed, so that a computer program read therefrom is installed into the storage section 908 as needed.

[0089] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 909, and / or installed from the removable medium 911. When the computer program is executed by the central processing unit (CPU) 901, the above functions defined in the method of the present application are executed. It should be noted that the computer-readable storage medium of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection with one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, device, or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wireless, wireline, optical cable, RF, etc., or any suitable combination of the foregoing.

[0090] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate 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 a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0091] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0092] The modules involved in the embodiments of the present application may be implemented by software or hardware.

[0093] As another aspect, the present application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiment; or it may exist independently and not be assembled into the electronic device. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed by the electronic device, the electronic device: obtains the file size and image reading offset of the TBI backup image file; in response to the image reading offset being less than the file size, reads the preset byte data from the file header, and sequentially determines whether the preset byte data meets the device information storage block requirements, whether the image header ends, whether it reaches the partition storage start position, whether it reaches the partition tail, and whether the data is the partition tail information storage location identifier; in the judgment process, adjusts the read offset according to different judgment results, and performs data reading and parsing operations according to the data type; continues the above judgment, offset adjustment, data reading and parsing operations until the image file reading is completed.

[0094] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above invention concept. For example, the above features are replaced with the technical features with similar functions disclosed in this application (but not limited to) by each other to form a technical solution.

Claims

1. A method for recovering a damaged TBI backup image, characterized in that: include: S1: Get the file size and image read offset of the TBI backup image file; S2: In response to the image read offset being smaller than the file size, read preset byte data from the file header, and sequentially determine whether the preset byte data meets the device information storage block requirement, whether the image header ends, whether the partition storage start position is reached, whether the partition tail is reached, and whether the data is a partition tail information storage position identifier; S3: In the judgment process of S2, the read offset is adjusted according to different judgment results, and at the same time, data reading and parsing operations are performed according to the data type, including parsing special block data and common block data; S4: Continue the above-mentioned determination, offset adjustment, data reading and parsing operations until the image file reading is completed.

2. The method for recovering a damaged TBI backup image according to claim 1, characterized in that: The preset byte data is 12 bytes of data read from the file header.

3. The method for recovering a damaged TBI backup image according to claim 2, characterized in that: In S2, judging whether the preset byte data meets the requirements of the device information storage block is specifically judging whether the read preset byte data is 0x01, and the block length is 0x198 of the device information storage block. If so, the file offset is adjusted according to the storage structure of the 0x01 block of the image header storage structure partition, the file offset is increased by 12 bytes, and on this basis, 0x198 bytes are added, and the relationship between the image reading offset and the file size is re-judged; if not, a judgment is made as to whether the image header ends.

4. The method for recovering a damaged TBI backup image according to claim 3, characterized in that: The judgment of whether the image header ends is specifically to judge whether the preset byte data is 0xFFFFFFFF000000000FFFFFFFF. If so, the file offset is increased by 1 byte, and the relationship between the image read offset and the file size is re-judged; if not, the file offset is increased by 0x0C bytes to determine whether the partition storage start position is reached.

5. The method for recovering a damaged TBI backup image according to claim 4, characterized in that: The determination of whether the partition storage start position has been reached is specifically to read 8 bytes of data from the current file position and store them in the space pointed to by the buffer pointer pBuf, analyze the data in the pBuf, determine whether the partition storage start position has been reached, if so, increase the file offset by 16 bytes, and determine whether the partition end has been reached, if not, increase the file offset by 1 byte, and re-determine the relationship between the image read offset and the file size.

6. The method for recovering a damaged TBI backup image according to claim 5, characterized in that: The judgment of whether the end of the partition has been reached is specifically to read 8 bytes of data from the current file position and store them into the space pointed to by the buffer pointer pBuf, analyze the data in the pBuf to determine whether it indicates that the end of the partition has been reached, if so, increase the file offset by 8 bytes, obtain the lower 16 bits of data in pBuf through the pBuf&0x0000FFFF operation and convert it into an integer and add it to the file offset, read 8 bytes of data from the new offset position into the buffer again, extract the lower 16 bits of data in pBuf again, convert it into an integer and add it to the file offset, and judge the storage location identifier of the partition tail information.

7. The method for recovering a damaged TBI backup image according to claim 6, characterized in that: If the end of the partition is not reached, further determine whether the read data is special block data. If it is special block data, increase the file offset by 8 bytes, read 0x0C bytes of data from the current offset position, and parse the data according to the special block structure to obtain the offset position information of the next data block. After obtaining the offset position, add the offset to the file offset so that the offset points to the new position. After completing the processing of the special block data, continue to determine whether the image file is read; if it is not special block data, increase the file offset by 8 bytes, extract the lower 16 bits of data in the pBuf, convert them into integers, and add them to the file offset so that the offset points to the starting position of the next data block. After completing data parsing and offset adjustment, continue to read the image file.

8. The method for recovering a damaged TBI backup image according to claim 6, characterized in that: The determination of the partition tail information storage position identifier specifically includes obtaining whether the partition tail information storage position identifier is contained in the current data, and if so, converting the lower 16 bits of the data in the pBuf into an integer value to determine the file reading offset position according to the partition tail information storage structure obtained in advance, adding the integer value to the file offset, and continuing to determine whether the subsequent data still has partition tail information or whether the partition data part has been processed; If not, increase the file read offset by 8 bytes and continue to determine and process the partition tail information.

9. A computer-readable storage medium having one or more computer programs stored thereon, characterized in that: When the one or more computer programs are executed by a computer processor, the method according to any one of claims 1 to 8 is implemented.

10. A recovery system for a damaged TBI backup image, characterized in that: include: A data acquisition unit configured to acquire a file size and an image reading offset of a TBI backup image file; a judgment unit configured to read preset byte data from the file header in response to the image read offset being smaller than the file size, and to sequentially judge whether the preset byte data meets the device information storage block requirement, whether the image header ends, whether the partition storage start position is reached, whether the partition tail is reached, and whether the data is a partition tail information storage position identifier; an adjustment and parsing unit configured to adjust the read offset according to different judgment results during the judgment process of the judgment unit, and at the same time, perform data reading and parsing operations according to the data type, including parsing special block data and ordinary block data; The recovery control unit is configured to continue the above-mentioned determination, offset adjustment, data reading and parsing operations until the image file reading is completed.

11. The system for recovering a damaged TBI backup image according to claim 10, characterized in that: The preset byte data is 12 bytes of data read from the file header.

12. The system for recovering a damaged TBI backup image according to claim 10, characterized in that: The judging unit specifically includes: Determine whether the preset byte data meets the device information storage block requirements: determine whether the preset byte data read is 0x01, and the device information storage block with a block length of 0x198, if so, adjust the file offset according to the storage structure of the 0x01 block of the image header storage structure partition, increase the file offset by 12 bytes, and then increase 0x198 bytes on this basis, and re-determine the relationship between the image read offset and the file size; if not, determine whether the image header ends; Determine whether the image header ends: determine whether the preset byte data is 0xFFFFFFFF000000000FFFFFFFF, if so, increase the file offset by 1 byte, and re-determine the relationship between the image read offset and the file size; if not, increase the file offset by 0x0C bytes to determine whether the partition storage start position is reached; Determine whether the partition storage start position has been reached: read 8 bytes of data from the current file position and store them in the space pointed to by the buffer pointer pBuf, analyze the data in the pBuf, determine whether the partition storage start position has been reached, if so, increase the file offset by 16 bytes, and determine whether the partition end has been reached, if not, increase the file offset by 1 byte, and re-determine the relationship between the image read offset and the file size; Determine whether the partition tail has been reached: read 8 bytes of data from the current file position and store them in the space pointed to by the buffer pointer pBuf, analyze the data in the pBuf to determine whether it indicates that the partition tail has been reached, if so, increase the file offset by 8 bytes, obtain the lower 16 bits of data in pBuf through the pBuf&0x0000FFFF operation and convert it into an integer and add it to the file offset, read 8 bytes of data from the new offset position to the buffer again, extract the lower 16 bits of data in pBuf again, convert it into an integer and add it to the file offset, and determine the storage location identifier of the partition tail information; Determine the partition tail information storage location identifier: obtain whether the partition tail information storage location identifier is contained in the current data; if so, determine the file read offset position by converting the lower 16 bits of the data in the pBuf into an integer value based on the partition tail information storage structure obtained in advance, add the integer value to the file offset, and continue to determine whether the subsequent data still has partition tail information or whether the partition data part has been processed; if not, increase the file read offset by 8 bytes, and continue to determine and process the partition tail information.

13. The system for recovering a damaged TBI backup image according to claim 12, characterized in that: If the end of the partition is not reached, further determine whether the read data is special block data. If it is special block data, increase the file offset by 8 bytes, read 0x0C bytes of data from the current offset position, and parse the data according to the special block structure to obtain the offset position information of the next data block. After obtaining the offset position, add the offset to the file offset so that the offset points to the new position. After completing the processing of the special block data, continue to determine whether the image file is read; if it is not special block data, increase the file offset by 8 bytes, extract the lower 16 bits of data in the pBuf, convert them into integers, and add them to the file offset so that the offset points to the starting position of the next data block. After completing data parsing and offset adjustment, continue to read the image file.

Images