Equipment failure recovery method and device, storage medium and computer equipment

Abstract

The invention provides an equipment failure recovery method and device, a storage medium and computer equipment, and the method comprises the steps: recording the writing operation of each storage region of a file system in real time when a key file is written into the file system, and writing a log record corresponding to each storage region into a preset log file. Determining a target log record corresponding to each storage area in the log file when equipment to which the file system belongs fails and restarts after the failure is eliminated in the process; therefore, whether the key file is completely written into the storage area or not can be judged according to the target log record of each storage area. And then determining the uncompleted areas in the storage areas according to the target log records corresponding to the storage areas, and regenerating the damaged files after identifying the damaged files, so as to accurately identify the damaged files caused at the moment of fault occurrence, so that services relying on the damaged files can run normally, and the service efficiency is improved. And normal starting of the equipment of the file system is ensured.

Description

Technical Field

[0001] The present application relates to the technical field of equipment maintenance, and in particular to an equipment failure recovery method, device, storage medium and computer equipment. Background Art

[0002] In the current digital storage field, the F2FS file system is widely used in many electronic devices due to its friendly adaptability to flash memory devices. However, the F2FS file system is prone to file corruption and other problems when it fails. Some devices that strongly rely on files may not be able to start normally once they are damaged. In this regard, traditional data protection methods often rely on regular backups or the file system's own built-in fault tolerance mechanism to maintain data integrity and availability.

[0003] However, traditional data protection methods are unable to protect critical files being written when faced with sudden failures. After the cause of the failure is eliminated, the services that rely on these critical files cannot operate normally due to the damage to the critical files, causing the device to be stuck on the boot page and unable to start, which has a negative impact on the reliability of the device. Summary of the invention

[0004] The purpose of the present application is to solve at least one of the above-mentioned technical defects, especially the technical defect that it is difficult to protect the key files being written in the face of sudden failures in the prior art, and after the cause of the failure is eliminated, the services that rely on these key files cannot run normally due to the damage of the key files, causing the device to be stuck on the boot page and unable to start, thereby having a negative impact on the reliability of the device.

[0005] In a first aspect, the present application provides a device failure recovery method, the method comprising:

[0006] When it is detected that a key file is written into the file system, the write operation of each storage area of ​​the file system is recorded in real time to obtain a log record corresponding to each storage area; the key file is a strongly dependent file of the device to which the file system belongs;

[0007] Write the log records corresponding to each storage area into the preset log file respectively;

[0008] When a device to which the file system belongs fails and the failure is eliminated and restarted during the process of writing the key file into the file system, the log file is read, and a target log record corresponding to each storage area is determined in the log file;

[0009] The unfinished areas in each storage area are determined according to the target log records corresponding to each storage area, and after the damaged files are identified according to the target log records corresponding to each unfinished area, each damaged file is regenerated to ensure that the device to which the file system belongs starts normally.

[0010] In one embodiment, the real-time recording of the write operation of each storage area of ​​the file system to obtain a log record corresponding to each storage area includes:

[0011] For each storage area of ​​the file system, determining in real time the current writing status and integrity mark of the storage area;

[0012] The file identifier of the currently written key file and the area identifier of the storage area are obtained, and a log record of the storage area at the current moment is formed according to the file identifier, the area identifier, the writing status and the integrity mark.

[0013] In one embodiment, the real-time determination of the current write status and integrity flag of the storage area includes:

[0014] Detecting the current file writing situation of the storage area, and determining the current writing state according to the file writing situation; the writing state includes written, writing in progress and not written;

[0015] If the current write status is already written, the current integrity flag is set to an identifier representing data integrity;

[0016] If the current writing status is writing in progress or not written, the current integrity flag is set to a flag indicating that the data is incomplete.

[0017] In one embodiment, writing the log records corresponding to each storage area into a preset log file includes:

[0018] Determine the preset log file;

[0019] For each storage area of ​​the file system, a log record generated when a real-time write operation is recorded on the storage area is written into the log file.

[0020] In one embodiment, reading the log file and determining the target log record corresponding to each storage area in the log file includes:

[0021] Read each log record in the log file, and divide the read log records according to their corresponding storage areas to obtain a record set corresponding to each storage area;

[0022] For each storage area, the log record with the latest recording time in each partitioning dimension is selected from the record set of the storage area using the file identifier as the partitioning dimension as the target log record corresponding to the storage area.

[0023] In one embodiment, determining the unfinished area in each storage area according to the target log record corresponding to each storage area includes:

[0024] Obtaining the integrity flag in the target log record corresponding to each storage area;

[0025] A storage area corresponding to a target log record having an integrity mark indicating incomplete data is determined as an unfinished area.

[0026] In one embodiment, after identifying damaged files according to target log records corresponding to each unfinished area, regenerating each damaged file includes:

[0027] Extracting a file identifier from each target log record corresponding to each unfinished area to obtain a file identifier set;

[0028] Performing a deduplication operation on the file identification set, and determining a key file corresponding to each file identification in the deduplication-operated file identification set;

[0029] The key file corresponding to each file identifier in the file identifier set that has undergone the deduplication operation is determined as a damaged file, and the operation of deleting and regenerating each determined damaged file is performed.

[0030] In a second aspect, the present application provides a device failure recovery apparatus, the apparatus comprising:

[0031] A log recording module is used to record the write operation of each storage area of ​​the file system in real time when it is detected that a key file is written into the file system, and obtain a log record corresponding to each storage area; the key file is a strongly dependent file of the device to which the file system belongs;

[0032] The log writing module is used to write the log records corresponding to each storage area into a preset log file;

[0033] a record determination module, configured to read the log file and determine a target log record corresponding to each storage area in the log file when a device to which the file system belongs fails and the failure is eliminated and restarted during the process of writing the key file into the file system;

[0034] The file regeneration module is used to determine the unfinished area in each storage area according to the target log record corresponding to each storage area, and after identifying the damaged files according to the target log record corresponding to each unfinished area, regenerate each damaged file to ensure that the device to which the file system belongs starts normally.

[0035] In a third aspect, the present application provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the device failure recovery method described in any of the above embodiments.

[0036] In a fourth aspect, the present application provides a computer device, comprising: one or more processors, and a memory;

[0037] The memory stores computer-readable instructions, and when the one or more processors execute the computer-readable instructions, the steps of the device failure recovery method described in any one of the above embodiments are performed.

[0038] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0039] The present application provides a device failure recovery method, apparatus, storage medium and computer equipment, the method comprising: when a key file is detected to be written into a file system, the write operation of each storage area of ​​the file system is recorded in real time to obtain a log record corresponding to each storage area, wherein the key file is a strongly dependent file of the device to which the file system belongs, and then the log record corresponding to each storage area is written into a preset log file. Since the data stored in the log file will not be lost due to a failure, the writing status of the key file can be determined according to the log file after the device is restarted. When a device to which the file system belongs fails and the failure is eliminated and the device restarts during the process of writing key files to the file system, the log file is read and the target log record corresponding to each storage area is determined in the log file; in this way, it is possible to determine whether the key files are completely written to the storage area based on the target log record of each storage area, and because it is a real-time log record, it is possible to restore the situation of the key files at the time of the failure, and then determine the unfinished areas in each storage area based on the target log record corresponding to each storage area, and after identifying the damaged files based on the target log record corresponding to each unfinished area, each damaged file is regenerated after the damaged files are determined, so as to accurately identify the damaged files caused by the time of the failure, so that the services that rely on these damaged files can operate normally, ensure that the devices to which the file system belongs start normally, and thus improve the reliability of the device. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0041] Figure 1 A schematic diagram of a process flow of a device failure recovery method provided in an embodiment of the present application;

[0042] Figure 2 A schematic diagram of a flow chart of a write operation of each storage area of ​​a real-time recording file system provided in an embodiment of the present application;

[0043] Figure 3 A schematic diagram of a process for regenerating each damaged file after identifying damaged files according to target log records corresponding to each unfinished area provided in an embodiment of the present application;

[0044] Figure 4 A schematic diagram of the structure of a device failure recovery device provided in an embodiment of the present application;

[0045] Figure 5 An internal structure diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0047] In the current digital storage field, the F2FS file system is widely used in many electronic devices due to its friendly adaptability to flash memory devices. However, the F2FS file system is prone to file corruption and other problems when it fails. Some devices that strongly rely on files may not be able to start normally once they are damaged. In this regard, traditional data protection methods often rely on regular backups or the file system's own built-in fault tolerance mechanism to maintain data integrity and availability.

[0048] However, traditional data protection methods are difficult to protect key files being written when facing sudden failures. After the cause of the failure is eliminated, the damage to the key files causes the services that rely on these key files to fail to operate normally, causing the device to be stuck on the boot page and unable to start, thereby negatively affecting the reliability of the device. Based on this, the present application provides a device failure recovery method, and the following embodiments can be described by applying to a file system, hereinafter referred to as a system, such as Figure 1 As shown, the device failure recovery method includes:

[0049] S101: When it is detected that a key file is written into the file system, the writing operation of each storage area of ​​the file system is recorded in real time to obtain a log record corresponding to each storage area.

[0050] The key file is a strongly dependent file of the device to which the file system belongs. The log record refers to a record formed by information generated by the write operation of the record storage area.

[0051] In this step, when the user enables the device fault recovery method, the system will detect the operation of writing key files to the file system. When the system detects that the key files are written to the file system, the system can record the write operation of each storage area in real time, so as to obtain the log record generated by each storage area each time the write operation is recorded.

[0052] It can be understood that key files include but are not limited to system configuration files, kernel files, driver software packages, etc. The device to which the file system belongs refers to the device on which the file system is deployed. When the device is started, there are some strongly dependent files, that is, files that must be correctly loaded and processed during the startup process of the device to ensure the smooth completion of the startup process, which are the key files in this application.

[0053] Specifically, a file system refers to a system used by an operating system to specify the organization, storage, retrieval, and management of data on a storage device. In an example, the file system may be an F2FS file system, which divides a storage device into the following storage areas: a Checkpoint area, a Segment Info Table (SIT) area, a Node Address Table (NAT) area, a Segment Summary Area (SSA) area, and a Main Area area.

[0054] S102: Write the log records corresponding to each storage area into a preset log file respectively.

[0055] The log file refers to a file storage area that does not cause data loss when a device fails.

[0056] In this step, for each storage area, the log records generated in the real-time record writing operation of the storage area are written into a preset log file, so that the security of the log records can be ensured when a device fails.

[0057] S103: When a device to which the file system belongs fails and the failure is eliminated and the device is restarted during the process of writing the key file into the file system, the log file is read, and a target log record corresponding to each storage area is determined in the log file.

[0058] In this step, during the process of writing any key file to the file system, when the device to which the file system belongs fails and restarts after the cause of the failure is eliminated, the system can read the log file and obtain the log records corresponding to each storage area therefrom, and then determine the target log records corresponding to each storage area in the log records of each storage area.

[0059] The target log record refers to the latest log record corresponding to different files in the log record corresponding to the storage area. It can be understood that since the target log record refers to the latest log record corresponding to different files, each storage area corresponds to at least one target log record. By determining the target log record corresponding to each storage area, the key file writing situation at the time of the failure can be restored, so that targeted file regeneration operations can be performed.

[0060] In an example, common failures that occur to the device to which the file system belongs include power failure, device crash, and the like.

[0061] S104: determining the unfinished areas in each storage area according to the target log records corresponding to each storage area, and after identifying the damaged files according to the target log records corresponding to each unfinished area, regenerating each damaged file to ensure that the device to which the file system belongs starts normally.

[0062] In this step, when determining the target log record corresponding to each storage area, the unfinished area where the key file is not completely written can be determined in each storage area according to the target log record corresponding to each storage area, and then the incomplete key file, that is, the damaged file, can be identified according to the target log record corresponding to each unfinished area. After the damaged file is identified, each damaged file is regenerated to ensure that the services corresponding to these damaged files can run normally when the device is started, so that the device can start normally.

[0063] The unfinished area refers to a storage area where key files that have not been completely written exist, and the damaged file refers to an incomplete key file.

[0064] In another embodiment, the steps of identifying damaged files and regenerating each damaged file may include: by evaluating the degree of damage of each damaged file, deleting and regenerating damaged files whose degree of damage is greater than a preset threshold, and repairing and generating damaged files whose degree of damage is not greater than the preset threshold.

[0065] It is understandable that through real-time logging, incomplete key files can be accurately determined when the device is started, so that these incomplete key files can be regenerated so that the corresponding services can run normally when the device is started, ensuring that the system's devices start normally.

[0066] The present application provides a device failure recovery method, apparatus, storage medium and computer equipment, the method comprising: when a key file is detected to be written into a file system, the write operation of each storage area of ​​the file system is recorded in real time to obtain a log record corresponding to each storage area, wherein the key file is a strongly dependent file of the device to which the file system belongs, and then the log record corresponding to each storage area is written into a preset log file. Since the data stored in the log file will not be lost due to a failure, the writing status of the key file can be determined according to the log file after the device is restarted. When a device to which the file system belongs fails and the failure is eliminated and the device restarts during the process of writing key files to the file system, the log file is read and the target log record corresponding to each storage area is determined in the log file; in this way, it is possible to determine whether the key files are completely written to the storage area based on the target log record of each storage area, and because it is a real-time log record, it is possible to restore the situation of the key files at the time of the failure, and then determine the unfinished areas in each storage area based on the target log record corresponding to each storage area, and after identifying the damaged files based on the target log record corresponding to each unfinished area, each damaged file is regenerated after the damaged files are determined, so as to accurately identify the damaged files caused by the time of the failure, so that the services that rely on these damaged files can operate normally, ensure that the devices to which the file system belongs start normally, and thus improve the reliability of the device.

[0067] like Figure 2 As shown, in one embodiment, the write operation of each storage area of ​​the file system is recorded in real time to obtain a log record corresponding to each storage area, including:

[0068] S201: For each storage area of ​​the file system, determine the current writing status and integrity flag of the storage area in real time.

[0069] The write status refers to the status information of the key file in the process of writing into the file system, and the integrity flag is used to identify whether the key file currently being written is written completely.

[0070] In this step, for each storage area in the file system, the current writing status and integrity flag of the storage area are determined in real time according to the writing status of the key file currently being written, so as to subsequently generate a corresponding log record.

[0071] S202: Obtain the file identifier of the key file currently being written and the area identifier of the storage area, and form a log record of the storage area at the current moment according to the file identifier, the area identifier, the writing status and the integrity flag.

[0072] The file identifier is used to identify a key file, and the area identifier is used to identify a storage area in the file system.

[0073] Specifically, the file identifier of the currently written key file and the area identifier of the storage area may be obtained, and then a log record of the storage area at the current moment may be generated according to the file identifier, the area identifier, the writing status and the integrity flag.

[0074] In this embodiment, the write status, integrity flag, file identifier and area identifier of each storage area of ​​the file system are recorded in real time to form a log record of each storage area, so that the write status when the failure occurs can be restored based on the log record of each storage area, and the damaged files can be accurately determined to perform targeted file regeneration, which can save resources and improve boot efficiency while ensuring the normal startup of the device.

[0075] In one embodiment, determining the current write status and integrity flag of the storage area in real time includes:

[0076] S1: Detect the current file writing status of the storage area, and determine the current writing state according to the file writing status.

[0077] The write status includes written, writing, and not written. The file writing status refers to the writing status of key files.

[0078] In this step, the current file writing status of the storage area is detected to obtain the file writing status, and then the current writing state is determined according to the file writing status. Finally, the current integrity flag is determined according to the current writing status.

[0079] S2: If the current write status is already written, the current integrity flag is set to an identifier representing data integrity.

[0080] S3: If the current writing status is writing or not written, the current integrity flag is set to a flag indicating that the data is incomplete.

[0081] In this embodiment, log records are generated by determining the write status and integrity flag in real time, so that the write status when the failure occurs can be restored based on the log records of each storage area, and the damaged files can be accurately determined to perform targeted file regeneration.

[0082] In one embodiment, the log records corresponding to each storage area are written into a preset log file, including:

[0083] S1: Determine the preset log file.

[0084] S2: For each storage area of ​​the file system, the log records generated when the real-time write operation is recorded for the storage area are written into a log file.

[0085] In this embodiment, the log records generated when each storage area performs real-time write operation records are written into a preset log file for subsequent viewing. In addition, since the log file will not cause data loss when the device fails, the log records can be obtained from the log file when the device is restarted to determine the writing status of the key file at the time of the failure.

[0086] In one embodiment, reading a log file and determining a target log record corresponding to each storage area in the log file includes:

[0087] S1: Read each log record in the log file, and divide the read log record according to its corresponding storage area to obtain a record set corresponding to each storage area.

[0088] In this step, each log record in the log file is read, and then the read log records are divided according to the storage areas to which they belong, and the log records obtained by dividing each storage area form a record set of the storage area.

[0089] S2: For each storage area, the log record with the latest recording time in each partitioning dimension is selected from the record set of the storage area using the file identifier as the partitioning dimension as the target log record corresponding to the storage area.

[0090] The file identifier is used to identify the key file.

[0091] In this step, the record set of the storage area is divided using the file identifier as the division dimension, that is, the record set of the storage area is further divided according to different key files, and then the log record with the latest recording time is determined in the subsets obtained from each division dimension as the target log record corresponding to the storage area. It should be noted that when there are multiple division dimensions, the storage area corresponds to multiple target log records.

[0092] For example, assuming that there are log records a, log records b, log records c and log records d in the log file, the storage areas to which each log record belongs and the files recorded are as follows: the storage area to which log record a belongs and the files recorded are storage area a and key file a respectively; the storage area to which log record b belongs and the files recorded are storage area b and key file b respectively; the storage area to which log record c belongs and the files recorded are storage area a and key file c respectively; the storage area to which log record d belongs and the files recorded are storage area b and key file b respectively. Then, a record set A corresponding to storage area a can be obtained, and record set A includes log records a and log records c, and a record set B corresponding to storage area b can be obtained, and record set B includes log records b and log records d. Then, further division is performed according to the file identifier. At this time, two division dimensions of key file a and key file c can be obtained for storage area a. Since both division dimensions contain only one log record, the target log records corresponding to storage area a are log records a and log records c. For storage area b, the partition dimension of key file b can be obtained. Since this partition dimension includes two log records, the target log record of storage area b can be determined according to the recording time of log record b and log record d.

[0093] In this embodiment, the latest log records of different key files in each storage area are determined to restore the writing status when the device failure occurs, thereby accurately determining the damaged files and ensuring the normal startup of the device.

[0094] In one embodiment, determining the unfinished area in each storage area according to the target log record corresponding to each storage area includes:

[0095] S1: Obtain the integrity flag in the target log record corresponding to each storage area.

[0096] S2: Determine the storage area corresponding to the target log record having the integrity mark indicating incomplete data as an unfinished area.

[0097] In this embodiment, for each storage area, the integrity flag in the target log record corresponding to the storage area is obtained, and when the integrity flag in any target log record corresponding to the storage area indicates that the data is incomplete, the storage area is determined as an unfinished area. By determining the unfinished area in each storage area, the damaged file is further determined, so that the damaged file is regenerated.

[0098] like Figure 3As shown, in one embodiment, after the damaged files are identified according to the target log records corresponding to each unfinished area, each damaged file is regenerated, including:

[0099] S301: extracting a file identifier from each target log record corresponding to each unfinished area to obtain a file identifier set.

[0100] S302: performing a deduplication operation on the file identification set, and determining a key file corresponding to each file identification in the deduplication-operated file identification set.

[0101] S303: Determine the key file corresponding to each file identifier in the set of file identifiers that have undergone the deduplication operation as a damaged file, and perform deletion and regeneration operations on each of the determined damaged files.

[0102] It is understandable that when a file is written to a file system, part of the data will be written to various storage areas. For example, when key file A is written to file system B, and file system B is an F2FS file system, the key status information of key file A will be written to the Checkpoint area, the segment information involved in key file A will be written to the Segment Info Table area, the metadata information of key file A will be written to the Node Address Table area, the overall status information of the segments related to key file A will be written to the Segment Summary Area area, and the actual content of key file A will be written to the Main Area area.

[0103] Specifically, this embodiment determines a set of file identifiers, and since the same key file may not be written completely in multiple storage areas, the set of file identifiers is deduplicated, and then the damaged files are determined based on the deduplicated set of file identifiers, and then the information of the determined damaged files is obtained to perform deletion and regeneration operations on each damaged file. In this way, services that rely on these damaged files can run normally, thereby ensuring the normal startup of the device.

[0104] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0105] The following is a description of a device failure recovery apparatus provided in an embodiment of the present application. The device failure recovery apparatus described below and the device failure recovery method described above can be referenced to each other.

[0106] like Figure 4 As shown, the present application provides a device failure recovery device 400, the device comprising:

[0107] The log recording module 401 is used to record the write operation of each storage area of ​​the file system in real time when it is detected that the key file is written into the file system, and obtain the log record corresponding to each storage area; the key file is a strongly dependent file of the device to which the file system belongs;

[0108] The log writing module 402 is used to write the log records corresponding to each storage area into a preset log file;

[0109] The record determination module 403 is used to read the log file and determine the target log record corresponding to each storage area in the log file when the device to which the file system belongs fails and the failure is eliminated and restarted during the process of writing the key file into the file system;

[0110] The file regeneration module 403 is used to determine the unfinished area in each storage area according to the target log record corresponding to each storage area, and after identifying the damaged files according to the target log record corresponding to each unfinished area, regenerate each damaged file to ensure that the device to which the file system belongs starts normally.

[0111] In one embodiment, the logging module includes:

[0112] The information determination submodule is used to determine the current writing status and integrity mark of each storage area of ​​the file system in real time;

[0113] The record generation submodule is used to obtain the file identifier of the key file currently being written and the area identifier of the storage area, and form a log record of the storage area at the current moment according to the file identifier, area identifier, writing status and integrity mark.

[0114] In one embodiment, the information determination submodule includes:

[0115] The detection unit is used to detect the current file writing status of the storage area and determine the current writing status according to the file writing status; the writing status includes written, writing and not written;

[0116] A first setting unit is used to set the current integrity flag to an identifier representing data integrity if the current write status is already written;

[0117] The second setting unit is configured to set the current integrity flag to a flag indicating that the data is incomplete if the current writing state is writing in progress or not written yet.

[0118] In one embodiment, the log writing module includes:

[0119] A file determination submodule is used to determine a preset log file;

[0120] The log writing submodule is used to write the log records generated when the real-time write operation is recorded for each storage area of ​​the file system into the log file.

[0121] In one embodiment, the record determination module includes:

[0122] The set determination submodule is used to read each log record in the log file and divide the read log records according to their corresponding storage areas to obtain a record set corresponding to each storage area;

[0123] The record determination submodule is used to select, for each storage area, the log record with the latest recording time in each division dimension from the record set of the storage area using the file identifier as the division dimension as the target log record corresponding to the storage area.

[0124] In one embodiment, the file regeneration module includes:

[0125] A flag acquisition submodule is used to obtain the integrity flag in the target log record corresponding to each storage area;

[0126] The area determination submodule is used to determine the storage area corresponding to the target log record with the integrity mark indicating incomplete data as an unfinished area.

[0127] In one embodiment, the file regeneration module includes:

[0128] The identifier extraction submodule is used to extract the file identifier from each target log record corresponding to each unfinished area to obtain a file identifier set;

[0129] The identification deduplication submodule is used to perform a deduplication operation on the file identification set and determine the key file corresponding to each file identification in the file identification set that has undergone the deduplication operation;

[0130] The regeneration submodule is used to determine the key file corresponding to each file identifier in the file identifier set that has undergone the deduplication operation as a damaged file, and perform deletion and regeneration operations on each determined damaged file.

[0131] The division of each module in the above-mentioned device fault recovery device is only for illustration. In other embodiments, the device fault recovery device can be divided into different modules as needed to complete all or part of the functions of the above-mentioned device fault recovery device. Each module in the above-mentioned device fault recovery device can be implemented in whole or in part by software, hardware and a combination thereof. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0132] In one embodiment, the present application also provides a storage medium, in which computer-readable instructions are stored. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the device failure recovery method described in any of the above embodiments.

[0133] In one embodiment, the present application also provides a computer device having computer-readable instructions stored therein. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the device failure recovery method as described in any one of the above embodiments.

[0134] Indicatively, Figure 5 As shown, Figure 5 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of the present application. The computer device 500 may be provided as a server. Figure 5, the computer device 500 includes a processing component 502, which further includes one or more processors, and a memory resource represented by a memory 501, for storing instructions executable by the processing component 502, such as an application. The application stored in the memory 501 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 502 is configured to execute instructions to perform the device failure recovery method of any of the above embodiments.

[0135] The computer device 500 may further include a power supply component 503 configured to perform power management of the computer device 500, a wired or wireless network interface 504 configured to connect the computer device 500 to a network, and an input / output (I / O) interface 505. The computer device 500 may operate based on an operating system stored in the memory 501, such as Windows Server TM, Mac OS X TM, Unix TM, Linux TM, Free BSD TM, or the like.

[0136] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0137] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish an entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements not only include those elements, but also include other elements that are not clearly listed, or also include elements inherent to such process, method, article or equipment. In the absence of more restrictions, the elements limited by the sentence "comprise one..." do not exclude the existence of other identical elements in the process, method, article or equipment including the elements. Herein, the singular "one", "one" and "described / the" may also include plural forms, unless the context clearly indicates another way. It should also be understood that the terms "include / comprise" or "have" etc. specify the existence of stated features, wholes, steps, operations, components, parts or combinations thereof, but do not exclude the possibility of the existence or addition of one or more other features, wholes, steps, operations, components, parts or combinations thereof. At the same time, the term "and / or" used in this specification includes any and all combinations of the relevant listed items.

[0138] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can refer to each other.

[0139] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A device failure recovery method, characterized in that: The method comprises: When it is detected that a key file is written into the file system, the write operation of each storage area of ​​the file system is recorded in real time to obtain a log record corresponding to each storage area; the key file is a strongly dependent file of the device to which the file system belongs; Write the log records corresponding to each storage area into the preset log file respectively; When a device to which the file system belongs fails and the failure is eliminated and restarted during the process of writing the key file into the file system, the log file is read, and a target log record corresponding to each storage area is determined in the log file; The unfinished areas in each storage area are determined according to the target log records corresponding to each storage area, and after the damaged files are identified according to the target log records corresponding to each unfinished area, each damaged file is regenerated to ensure that the device to which the file system belongs starts normally.

2. The device failure recovery method according to claim 1, characterized in that: The real-time recording of the write operation of each storage area of ​​the file system to obtain a log record corresponding to each storage area includes: For each storage area of ​​the file system, determining in real time the current write status and integrity flag of the storage area; The file identifier of the currently written key file and the area identifier of the storage area are obtained, and a log record of the storage area at the current moment is formed according to the file identifier, the area identifier, the writing status and the integrity mark.

3. The device failure recovery method according to claim 2, characterized in that: The real-time determination of the current write status and integrity flag of the storage area includes: Detecting the current file writing situation of the storage area, and determining the current writing state according to the file writing situation; the writing state includes written, writing in progress and not written; If the current write status is already written, the current integrity flag is set to an identifier representing data integrity; If the current writing status is writing in progress or not written, the current integrity flag is set to a flag indicating that the data is incomplete.

4. The device failure recovery method according to claim 1, characterized in that: The step of writing the log records corresponding to each storage area into a preset log file comprises: Determine the preset log file; For each storage area of ​​the file system, a log record generated when a real-time write operation is recorded on the storage area is written into the log file.

5. The device failure recovery method according to claim 1, characterized in that: The step of reading the log file and determining the target log record corresponding to each storage area in the log file includes: Read each log record in the log file, and divide the read log records according to their corresponding storage areas to obtain a record set corresponding to each storage area; For each storage area, the log record with the latest recording time in each partitioning dimension is selected from the record set of the storage area using the file identifier as the partitioning dimension as the target log record corresponding to the storage area.

6. The device failure recovery method according to claim 1, characterized in that: The determining of the unfinished area in each storage area according to the target log record corresponding to each storage area includes: Obtaining the integrity flag in the target log record corresponding to each storage area; A storage area corresponding to a target log record having an integrity mark indicating incomplete data is determined as an unfinished area.

7. The device failure recovery method according to claim 1, characterized in that: After the damaged files are identified according to the target log records corresponding to the unfinished areas, the damaged files are regenerated, including: Extract the file identifier from each target log record corresponding to each unfinished area to obtain a file identifier set; Performing a deduplication operation on the file identification set, and determining a key file corresponding to each file identification in the deduplication-operated file identification set; The key file corresponding to each file identifier in the file identifier set that has undergone the deduplication operation is determined as a damaged file, and the operation of deleting and regenerating each determined damaged file is performed.

8. A device failure recovery device, characterized in that: The device comprises: A log recording module is used to record the write operation of each storage area of ​​the file system in real time when it is detected that a key file is written into the file system, and obtain a log record corresponding to each storage area; the key file is a strongly dependent file of the device to which the file system belongs; The log writing module is used to write the log records corresponding to each storage area into a preset log file; a record determination module, configured to read the log file and determine a target log record corresponding to each storage area in the log file when a device to which the file system belongs fails and the failure is eliminated and restarted during the process of writing the key file into the file system; The file regeneration module is used to determine the unfinished area in each storage area according to the target log record corresponding to each storage area, and after identifying the damaged files according to the target log record corresponding to each unfinished area, regenerate each damaged file to ensure that the device to which the file system belongs starts normally.

9. A storage medium, characterized in that: The storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the device failure recovery method as described in any one of claims 1 to 7.

10. A computer device, characterized in that: include: one or more processors, and memory; The memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the device failure recovery method according to any one of claims 1 to 7 are performed.

Images