TWI890495B - Method and system for file recovery based on multiple snapshots - Google Patents

Abstract

Embodiments of the present application provide a method and system for file recovery based on multiple snapshots. In this application, during each time data is backing up for a snapshot, each backup file thereof is scanned to see if it is potentially damaged by ransomware, and if yes, marked as suspicious. For example, during consequent backup processes, a first file list and a second file list with files that may be marked are suspicious files are consequently generated. Then, when there is a need to perform data recovery, file(s) marked as suspicious in the second file list are replaced with corresponding file(s) in the first file list that is/are not marked as suspicious, in order to generate a candidate file list. Then, file recovery can be performed based on the generated candidate file list. This method can prevent the files that may be damaged by ransomware from being recovered to a target device and save the time and labor inspection required for data recovery.

Description

Method and system for file restoration based on multiple snapshots

The present application relates to the field of data management, and more particularly to a method and system for file restoration based on multiple snapshots.

Ransomware is a type of malware that destroys victims' data, typically by encrypting it, preventing users from accessing their files. Once encrypted, attackers demand a ransom to decrypt the files. This places financial pressure on victims, and even after paying the ransom, there's no guarantee that data will be fully recovered. Strengthening protection against and response to ransomware is crucial for data security.

To combat ransomware attacks, backup solutions have become a crucial last line of defense for businesses and government agencies. However, traditional backup solutions are insufficient to combat ransomware because they lack visibility into the integrity of backed-up files. This often leads to time-consuming manual verification of file contents across multiple backup snapshots when data recovery is required.

Furthermore, due to the unique nature of ransomware, traditional solutions for combating virus infections are inapplicable to ransomware attacks. Traditional antivirus software uses virus definition libraries to detect and isolate known viruses, and these libraries must be regularly updated to identify new virus variants. Once a file is infected by a virus, it is typically necessary to isolate the infected file, and sometimes it is possible to remove the virus. However, when files are damaged by ransomware, the encryption algorithm often extensively damages the file contents, making them impossible to decrypt and restore without the original encryption key. Therefore, if files are damaged by ransomware, it is practically necessary to back up the files in advance to increase the likelihood of recovering the encrypted data. Therefore, anti-virus solutions cannot overcome the threat of ransomware.

When it comes to ransomware data recovery, there are two main types of techniques: recovering data from a single snapshot, and recovering data from multiple snapshots.

The most straightforward way to restore data from a single snapshot is to restore files from the most recent snapshot. Another approach is to observe and infer the time of the ransomware attack through the operating system (for example, by detecting an unusual increase in file access behavior or setting up a honeypot to detect ransomware). Then, manually or automatically, restore files from a snapshot before the attack. However, this method cannot completely guarantee that the restored snapshot is clean; the restored data may still contain files damaged by ransomware. Users still need to take the time to manually verify the restored files to ensure that each file is in its "clean" state before the attack.

Restoring data from multiple snapshots involves mounting and scanning each snapshot one by one to identify files within each snapshot that have not been damaged by the ransomware. The modified dates of these files are then compared, and data recovery is performed based on the most recent files that have not been damaged by the ransomware. However, this method of mounting and scanning each snapshot individually is time-consuming and cannot meet the requirements for rapid data recovery, especially when a business is attacked, where rapid file recovery is crucial.

Therefore, it is necessary to improve and optimize the existing file restoration methods.

This application embodiment provides a method and system for restoring files based on multiple snapshots, which can improve the efficiency of data restoration. The technical solution is as follows:

According to one aspect of an embodiment of the present application, a method for restoring files based on multiple snapshots is provided, comprising: receiving multiple files stored on an endpoint device, backing them up as a first snapshot, and storing a first file list corresponding to the first snapshot; when backing up the first snapshot, detecting whether the file format of each file is damaged, and if the file format of any file is damaged, marking the file as a suspicious file in the first file list; receiving multiple files stored on the endpoint device, backing them up as a second snapshot, and storing a second file list corresponding to the second snapshot; and when backing up the second snapshot, When taking a snapshot, the system detects whether the file format of each file is damaged. If the file format of a file is damaged, the system marks the file as a suspicious file in the second file list. When a restore request is received from the endpoint device, the system reads the first file list and the second file list, replaces the files marked as suspicious files in the second file list with corresponding files in the first file list that are not marked as suspicious files, so as to generate a candidate file list. In response to the restore request, the system sends the candidate file list to the endpoint device so that the file is restored based on the candidate file list.

In the embodiment of the present application, the method further includes: detecting whether there is an associated file for the file marked as a suspicious file in the second file list; detecting whether the corresponding associated file in the first file list is not marked as a suspicious file; and replacing the associated file in the second file list with the corresponding associated file in the first file list that is not marked as a suspicious file to generate the candidate file list.

In the embodiment of the present application, the associated files refer to files based on a combination of one or more of the following: files located in the same folder, files of related types, files with a dependent relationship, and files modified at the same time.

In the embodiment of the present application, the method further includes: detecting the endpoint device with the candidate file list to detect whether the file format of the corresponding file in the endpoint device is damaged; if not, optimizing out one or more corresponding files from the candidate file list; and performing file recovery based on the optimized candidate file list.

In the embodiment of the present application, the detection of whether the file format is damaged or whether it is a suspicious file is based on at least one of the following: detecting whether the file can be opened by any software application; detecting whether the file can be parsed by any file parser; and detecting whether the file content entropy value of the file is high.

In this application embodiment, the method further includes: restoring the files in the snapshot to the endpoint device based on the candidate file list.

In this embodiment of the application, the method further includes: restoring the files in the snapshot to a second endpoint device other than the endpoint device based on the candidate file list.

In this embodiment of the application, the method further includes: if the corresponding file in the second file list is marked as a suspicious file, receiving a third file list corresponding to the third snapshot; merging the files in the third file list that are not marked as suspicious files into the candidate file list to generate an updated candidate file list; and sending the updated candidate file list to the endpoint device in response to the update request.

In the embodiment of the present application, in order to preserve the current status of the files of the endpoint device when they are damaged, the method further includes: if the backup file obtained from the snapshot during restoration will overwrite one or more files of the endpoint device, then the one or more files are first copied to another folder.

In the embodiment of the present application, in order to preserve the current status of the files of the endpoint device when they are damaged, the method further includes: placing the backup files obtained from the snapshot into other folders to avoid overwriting one or more original files of the endpoint device.

According to another aspect of an embodiment of the present application, a system for performing file recovery based on multiple snapshots is provided, comprising: a processor; and a memory connected to the processor, the memory storing multiple instructions that can be executed by the processor to perform the above method.

The technical solution provided by the embodiment of this application can include the following beneficial effects:

In the method and system for restoring files based on multiple snapshots of the present application, each backup file is scanned during each data backup to identify files damaged by ransomware as suspicious. For example, during two data backups, a first list of files potentially marked as suspicious and a second list of files potentially marked as suspicious are generated. Later, when data restoration is required, the first and second lists are read, and files marked as suspicious in the second list are replaced with corresponding files in the first list that are not marked as suspicious, to generate a candidate list of files. File restoration can then be performed based on this generated candidate list of files. Because suspicious files are marked beforehand during data restoration, files that may have been damaged by ransomware can be avoided from being restored to the target device. Furthermore, by quickly compiling a list of candidate files that exclude suspicious files for data restoration, the time and even manpower required for data restoration can be significantly reduced.

The following, combined with the accompanying drawings, provides a clear and complete description of the technical solutions in the embodiments of this application. Obviously, the described embodiments represent only a portion of the embodiments of this application, not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of this application without inventive effort are also within the scope of protection of this application.

This embodiment of the application provides a backup solution to protect against ransomware attacks. Specifically, during each backup, the contents of each backup file are scanned, and files damaged by ransomware are marked as suspicious. Therefore, when restoring data from multiple snapshots, a list of candidate files that excludes suspicious files can be quickly compiled for restoration, significantly reducing the time required for data restoration and improving data restoration efficiency. Furthermore, since each backup file is known to be suspicious, it is effectively prevented from containing files encrypted by ransomware after restoration.

FIG1 shows a block diagram of a system 10 for restoring files based on multiple snapshots according to an embodiment of the present application. As shown in FIG1 , the system 10 includes a backup module 11, a checklist generation module 12, and a restore module 13. The backup module 11 may further include a backup unit 110, a detection unit 120, and a marking unit 130. The checklist generation module 12 is connected between the backup module 11 and the restore module 13.

The system 10 can be implemented using software or firmware running on standalone hardware, or a combination of any two or more of these. In this embodiment of the present application, the backup module 11, the list generation module 12, and the restore module 13 can be software modules implemented via program code. The system 10 in this embodiment of the present application can be run on a computer device with a processor and memory, or on a server in a computer environment (e.g., a cloud storage server). This system can be used to mark files damaged by ransomware as suspicious during data backup, and then quickly exclude these suspicious files during data restoration.

The backup module 11 is used to perform data backup. Specifically, the backup unit 110 of the backup module 11 can back up one or more files from the endpoint device as a snapshot of the endpoint device and generate a file list corresponding to these files. During the backup process, the detection unit 120 detects whether the file format of each file is damaged (for example, detecting whether the file can be opened with any software application, comparing whether the previous version of the file can be opened with any software application, detecting whether the file can be parsed by any file parser, comparing whether the previous version of the file can be parsed by any file parser, detecting whether the file content entropy value of the file is too high, and comparing whether the file entropy value of the previous version of the file is too high). If the file format of a file is damaged, it may be a file attacked by ransomware and can be considered as a suspicious file. When the detection unit 120 detects that the file format of a file is damaged, the marking unit 130 marks the file as a suspicious file in the file list.

The backup module 11 executes the above process each time it performs a data backup. For example, during a data backup process performed at a first time point, the backup unit 110 receives one or more files stored on an endpoint device, backs up the files into a first snapshot, and stores a first file list corresponding to the first snapshot. During another data backup process performed at a second time point, the backup unit 110 receives one or more files stored on the same endpoint device, backs up the files into a second snapshot, and stores a second file list corresponding to the second snapshot. For example, the second time point is later than the first time point, meaning that the first snapshot is an earlier backup time and the second snapshot is a later backup time. When backup unit 110 backs up the first snapshot, detection unit 120 detects whether the file format of each file is corrupted. If the file format of the file is corrupted, marking unit 130 marks the file as a suspicious file in the first file list. When backup unit 110 backs up the second snapshot, detection unit 120 detects whether the file format of each file is corrupted. If the file format of the file is corrupted, marking unit 130 marks the file as a suspicious file in the second file list. Of course, data backup is not limited to the two backup processes described above. There are many other backup processes. The above two backup processes are merely examples.

When a user wishes to restore data, system 10 receives a restore request from the user. In response to the restore request, list generation module 12 receives the first and second file lists from backup module 11. Based on these lists, it generates a candidate file list, allowing subsequent data restore operations to be performed based on this candidate file list. It should be noted that if the first and/or second file lists include suspicious file flags, the file list received by list generation module 12 from backup module 11 will also include these suspicious file flags.

When generating the candidate files, list generation module 12 replaces the files marked as suspicious in the second file list with the corresponding files in the first file list that are not marked as suspicious. In other words, if a suspicious file that may have been corrupted by ransomware is found in the second snapshot (backed up later), list generation module 12 can search for an uncorrupted version of the file in an earlier snapshot (e.g., the first snapshot) and record it in the candidate file list. This uncorrupted version can then be used for restoration during subsequent data recovery. If the list generation module 12 cannot find an undamaged version of the file from the snapshot with an earlier backup time, the list generation module 12 can remove the file from the candidate file list to prevent files damaged by ransomware from being restored to the endpoint device. Files in the second file list that are not marked as suspicious files, i.e., normal files, may have modification or creation times later than the corresponding files in the first file list. Therefore, recording the normal files in the second file list in the candidate file list allows data to be restored using file versions that are more recent than the current time point.

As previously described, system 10 includes a restore module 13, which is configured to restore candidate files recorded in the candidate file list based on the candidate file list. For example, restore module 13 can restore the candidate files to an endpoint device, which can be a cloud storage device or a local storage device. Restoration module 13 can also help the endpoint device retrieve files to be restored from multiple snapshots based on the candidate file list and transfer these files to the endpoint device. In other embodiments, restoration module 13 can also restore files in a snapshot to a second endpoint device other than the endpoint device based on the candidate file list.

Of course, the system 10 may also not include the restore module 13. In response to a restore request from an endpoint device, the system 10 may simply send the candidate file list to the endpoint device. The endpoint device may then confirm each candidate file to be restored as recorded in the candidate file list, modify or adjust the candidate files to be restored if necessary, and then perform file restoration based on the confirmed candidate files.

The above description of system 10 is only a part of the embodiment of this application, and the embodiments of this application are not limited thereto. The embodiments described below and the embodiments described in the accompanying flowchart should still be considered as embodiments applicable to the operation of system 10.

FIG2 is a flowchart illustrating a method for restoring a file based on multiple snapshots according to an embodiment of the present application. The file restoration method disclosed in FIG2 can be implemented in conjunction with the system 10 of FIG1 .

As shown in steps S20 to S23 in FIG. 2 , the backup module 11 generates a file list corresponding to a snapshot each time a data backup is performed, detects whether the backup file is a suspicious file damaged by ransomware, and marks the suspicious file in the file list.

Consider two data backup processes (there are many other data backup processes, not just these). Please refer to Figure 2 in conjunction with Figure 3. In an earlier data backup process, backup unit 110 receives multiple files stored on an endpoint device, backs them up as a first snapshot S1, and stores a first file list corresponding to the first snapshot S1 (step S20). As shown in Figure 3, the first file list records files F11, F12, F13, and F14. When backup unit 110 backs up the first snapshot S1, detection unit 120 checks the file format of each file for corruption. If the file format is corrupted, marking unit 130 marks the file as suspicious in the first file list (step S21). As shown in Figure 3, in this example, files F11, F12, F13, and F14 are all normal files, not suspicious files. During a later data backup process, backup unit 110 receives multiple files stored on the same endpoint device, backs them up as a second snapshot S2, and stores a second file list corresponding to this second snapshot S2 (step S22). As shown in Figure 3, this second file list records files F21, F22, F23, and F24. When backup unit 110 backs up the second snapshot S2, detection unit 120 checks whether the file format of each file is corrupted. If the file format is corrupted, marking unit 130 marks the file as a suspicious file in the second file list (step S23). As shown in Figure 3, in this example, file F22 is a suspicious file, while files F21, F23, and F24 are all normal files, not suspicious files.

It should be noted that whether a file's file format is corrupted can be determined by testing whether the file can be opened with any corresponding software application, whether the file can be parsed by any file parser, or by testing whether the file's file content entropy is high, or by a combination of these or other testing methods. However, the method for detecting whether a file is corrupted is not the focus of this invention and is merely a few examples listed for illustrative purposes. This application is not limited thereto. If the file format is corrupted, it can be considered a file that may have been attacked by ransomware and is therefore marked as a suspicious file.

In this embodiment, each backup file is scanned during each data backup to mark files damaged by ransomware as suspicious. Although marking suspicious files takes a little longer than traditional backups, it helps to quickly avoid restoring files that may have been damaged by ransomware to the target device during the subsequent data recovery process, saving time waiting for data recovery at critical moments. In some scenarios, data recovery is urgent, and being able to shorten data recovery time is a significant benefit. The extra backup time is usually performed in the background. Since the time users need to back up data in normal times is much less than the time required to restore data in the event of an attack, it is consistent with common usage scenarios.

When the system 10 receives a restore request from the endpoint device (step S24), indicating that the user wishes to restore data, the list generation module 12 reads the first file list corresponding to the first snapshot S1 and the second file list corresponding to the second snapshot S2 (step S25) and generates a candidate file list 30 based on the first and second file lists. For a file in the second file list that is marked as a suspicious file, the list generation module 12 determines whether the file is not marked as a suspicious file in the first file list (if the file also exists in the first file list) (step S26). If so, the list generation module 12 replaces the file marked as a suspicious file in the second file list with the corresponding file in the first file list that is not marked as a suspicious file (step S27). Based on this rule, the candidate file list 30 is generated (step S28). To more clearly illustrate the steps of the present invention, let's take Figure 3 as an example. In the second snapshot S2, file F22 is marked as a suspicious file, while the corresponding file F12 in the first snapshot S1 is not. Therefore, the suspicious file F22 in the second snapshot S2 will be replaced by the normal file F12 in the first snapshot S1 and recorded in the candidate file list 30. In other words, if a suspicious file (e.g., file F22) that may be corrupted by ransomware is found in the second snapshot S2, which was backed up later, the list generation module 12 can search for an uncorrupted version of the file (e.g., file F12) in an earlier snapshot (e.g., the first snapshot S1) and record it in the candidate file list 30.

In step S29, the candidate file list 30 generated by the list generation module 12 is provided or sent to the endpoint device in response to the restore request, allowing the endpoint device to perform file restoration based on the candidate file list 30. Specifically, the endpoint device retrieves the files to be restored from the actual storage space of each snapshot (e.g., the first snapshot S1 and the second snapshot S2) based on the candidate files recorded in the candidate file list 30 to complete the data restoration. If necessary, the endpoint device can modify or adjust the candidate files to be restored based on the candidate file list 30 to perform data restoration.

To more clearly illustrate the steps of the present invention, let's use Figure 4 as an example. A source storage area 40 is attached to an endpoint device. Snapshot S0 is a full backup of source storage area 40. First snapshot S1 and second snapshot S2 are backups taken at a first and second time points, respectively, storing, including but not limited to, files modified or newly added to the full backup between the first and second time points. The actual storage space of snapshots S0, S1, and S3 may differ from that of source storage area 40. Continuing with the above example, file F22 in second snapshot S2 is marked as suspicious, so candidate file list 30 records files F21, F23, and F24 from the second snapshot S2 and file F12 from the first snapshot S1. Files F01, F02, F03, and F04 in source storage 40 were all damaged by ransomware and therefore require recovery. The files in candidate file list 30 are all "clean" (i.e., not damaged). Therefore, the damaged files in source storage 40 can be restored by retrieving the relevant files from the corresponding snapshots based on the files in candidate file list 30.

In other embodiments, the method may further include restoring files from snapshots (e.g., the first snapshot S1 and the second snapshot S2) to an endpoint device based on the candidate file list 30. Specifically, the restore module 13 may assist the endpoint device in retrieving files to be restored from multiple snapshots based on the candidate file list 30 and transferring these files to the endpoint device. This allows for rapid or automatic data recovery. In other embodiments, the method may further include restoring files from snapshots (e.g., the first snapshot S1 and the second snapshot S2) to a second endpoint device other than the endpoint device based on the candidate file list 30. Specifically, the restore module 13 may restore files from snapshots to a second endpoint device other than the endpoint device based on the candidate file list 30. This allows for remote recovery. Remote recovery often occurs when an endpoint device is attacked by ransomware and needs to undergo forensics before it can be immediately put back online.

In other embodiments, during the data restoration process, if the backup file obtained from the snapshot will overwrite a damaged file, the restore module 13 can first copy the damaged file to another folder. For example, the damaged file can be copied to a quarantine area to restrict access to the damaged file, preserving the current state of the file on the endpoint device at the time of the file damage. Additionally, copying the damaged file to another folder also achieves the effect of preserving it, preventing the file from being mistakenly identified as damaged and causing data loss. In other embodiments, the restore module 13 may place the backup file obtained from the snapshot into a folder different from the damaged file. In this way, before overwriting the original folder containing the damaged file, it is possible to check in advance whether the effect of the file restoration is the expected result.

In the method and system for restoring files based on multiple snapshots of the present application, each backup file is scanned during each data backup to identify files damaged by ransomware as suspicious. For example, during two data backups, a first list of files potentially marked as suspicious and a second list of files potentially marked as suspicious are generated. Later, when data restoration is required, the first and second lists are read, and files marked as suspicious in the second list are replaced with corresponding files in the first list that are not marked as suspicious, to generate a candidate list of files. File restoration can then be performed based on this generated candidate list of files. Because suspicious files are marked beforehand during data restoration, files that may have been damaged by ransomware can be avoided from being restored to the target device. Furthermore, by quickly compiling a list of candidate files that exclude suspicious files for data restoration, the time and even manpower required for data restoration can be significantly reduced.

FIG5 is a flowchart of a method for generating a candidate file list according to an embodiment of the present application. During the process of generating the candidate file list, in addition to replacing suspicious files in the second file list with normal files in the first file list, all files associated with the suspicious files in the second file list can also be grouped together, and the corresponding undamaged files in the first file list can be found based on this group to replace the files. Therefore, the method can further include detecting whether a file marked as suspicious in the second file list has any associated files (step S50), and detecting whether the corresponding associated files in the first file list are not marked as suspicious (step S51). When a suspicious file in the second file list has a file associated with it and an undamaged version of the associated file exists in the first file list, the associated file in the second file list can be replaced with the corresponding associated file in the first file list that is not marked as a suspicious file to generate a candidate file list (step S52).

For example, referring to Figure 6, the second snapshot S2 contains a suspicious file F22, and file F23 is associated with this suspicious file. Files F22 and F23 in the second snapshot S2 can be considered a group, corresponding to files F12 and F13 in the first snapshot S1. Since both files F12 and F13 are normal files, files F12 and F13 in the first snapshot S1 can be replaced with files F22 and F23 in the second snapshot S2.

These related files can be files located in the same folder, files of related types, files with dependencies, files modified during the same period, or a combination of two or more of the above. For example, ransomware may attack files belonging to the same software or system files. The files damaged by the ransomware may be related or dependent on each other, and different snapshots may store files in incompatible states. Therefore, it is sometimes necessary to restore files stored in the same snapshot to ensure normal operation of the software or system. For example, in various database systems such as MySQL, PostgreSQL, or Oracle, data files, transaction logs, and configuration files are closely related. Backing up or restoring only part of them without including others may lead to inconsistencies or data loss. Version control systems (VCSs), such as Git or Subversion, also have certain requirements. They manage repositories containing code, configuration files, and project history. To ensure consistency, backups or restores should include the entire repository, including metadata and branch-related files. Other systems, such as virtual machines, have similar requirements. A virtual machine image consists of disk files, snapshots, and configuration files. Backing up or restoring only the disk image without including the associated configuration files or snapshots can lead to difficulties in restoring the virtual machine to a consistent state.

Additionally, ransomware may target files located in the same project folder or of the same type. Restoring these files together can help maintain consistency after restoring business or public services. Furthermore, when attacked by ransomware, it may have modified a large number of files during the same period. Therefore, files modified during the same period can be considered related and recorded together in the candidate file list for restoration, ensuring consistency between files.

FIG7 is a flowchart of a method for locally optimizing a candidate file list according to an embodiment of the present application. The target device to be restored may not have all files damaged by the ransomware, and these undamaged files may be newer versions than those stored in the snapshot and therefore do not need to be restored. Therefore, the method may further include testing an endpoint device with the candidate file list generated in step S28 to detect whether the file format of corresponding files on the endpoint device is damaged. If not, optimizing one or more corresponding files from the candidate file list (step S70). Specifically, the candidate file list can be optimized locally to remove one or more files from the candidate file list, where these one or more files are determined to be non-suspicious files on the "local" endpoint device (i.e., the target device). After the candidate file list is optimized locally to produce an optimized candidate file list, file restoration can be performed based on the optimized candidate file list (step S71). Restoring data based on the optimized candidate file list can significantly reduce the number of files that need to be retrieved from each snapshot, while preserving newer versions of files as much as possible, further improving data restoration efficiency.

For example, see Figure 8. Files F02, F03, and F04 in the target device's source storage area 40 were damaged by ransomware. Continuing with the previous example, restoration would complete the candidate file list from file F12 in the first snapshot S1 and files F21, F23, and F24 in the second snapshot S2, respectively. However, since file F01 in source storage area 40 is a normal, undamaged file and is newer or at least the same version as the corresponding file in the snapshot (e.g., file F21 in the second snapshot S2), restoration is unnecessary. The candidate file list can be optimized locally based on this, removing file F21, which corresponds to file F01 in snapshot S2, from the candidate file list.

FIG9 shows a flowchart of a method for updating a candidate file list according to an embodiment of the present application. Files damaged by ransomware on a target device to be restored may not have corresponding, undamaged files in the candidate file list. In this case, a file list from one or more snapshots with earlier backup times may be imported and, based on the imported snapshots, the candidate file list may be updated to allow files available for restoration to be found from the earlier snapshots. Therefore, the method may further include receiving a third file list corresponding to a third snapshot if the corresponding file in the second file list is marked as suspicious (step S91). Files in the third file list that are not marked as suspicious may be merged into the candidate file list to generate an updated candidate file list (step S92). Specifically, if a file is marked as suspicious in both the first and second file lists, an undamaged version of the file can be searched for in the third file list for file restoration. Finally, in response to the update request, the updated candidate file list is sent to the endpoint device (i.e., the target device) (step S93), allowing data restoration based on this updated candidate file list. Restoring data based on the updated candidate file list allows files available for restoration to be found from snapshots with earlier backup times, significantly improving the success rate of data restoration. Please note that this embodiment can easily be extended to include more and earlier snapshots, so as to obtain the most recent and clean files from all available snapshots to generate the candidate file list, and this should not be considered a limitation of the present invention.

Although the present disclosure has been disclosed above using preferred embodiments, they are not intended to limit the present disclosure. Persons skilled in the art to which the present disclosure belongs may make various changes and modifications without departing from the spirit and scope of the present disclosure. Therefore, the scope of protection of the present disclosure shall be determined by the scope of the attached patent application.

10: System for restoring files based on multiple snapshots 11: Backup module 12: List generation module 13: Restoration module 30: Candidate file list 40: Source storage area 110: Backup unit 120: Detection unit 130: Marking unit F01-F04: Files F11-F14: Files F21-F24: Files S0: Snapshot S1: First snapshot S2: Second snapshot S20-S29: Steps S50-S52: Steps S70-S71: Steps S91-S93: Steps

To more clearly illustrate the technical solutions in the embodiments of this application, the following briefly introduces the figures used in describing the embodiments. It should be understood that the figures described below represent only some embodiments of this application. Those skilled in the art can derive other figures based on these figures without inventive effort. [Figure 1] shows a block diagram of a system for restoring files based on multiple snapshots in accordance with an embodiment of this application. [Figure 2] shows a flow chart of a method for restoring files based on multiple snapshots in accordance with an embodiment of this application. [Figure 3] shows a schematic diagram of the process for generating a candidate file list in accordance with an embodiment of this application. [Figure 4] shows a schematic diagram of a data restoration process in accordance with an embodiment of this application. [Figure 5] is a flowchart showing a method for generating a candidate file list according to an embodiment of the present application. [Figure 6] is a schematic diagram showing another process for generating a candidate file list according to an embodiment of the present application. [Figure 7] is a flowchart showing a method for optimizing a candidate file list according to an embodiment of the present application. [Figure 8] is a schematic diagram showing a process for optimizing a candidate file list according to an embodiment of the present application. [Figure 9] is a flowchart showing a method for updating a candidate file list according to an embodiment of the present application.

S20~S29: Steps

Claims (11)

A method for restoring files based on multiple snapshots comprises: Receiving multiple files stored on an endpoint device, backing them up as a first snapshot, and storing a first file list corresponding to the first snapshot; While backing up the first snapshot, detecting whether the file format of each file is corrupted, and if the file format of any file is corrupted, marking the file as a suspect file in the first file list; Receiving multiple files stored on the endpoint device, backing them up as a second snapshot, and storing a second file list corresponding to the second snapshot; While backing up the second snapshot, detecting whether the file format of each file is corrupted, and if the file format of any file is corrupted, marking the file as a suspect file in the second file list; Upon receiving a restore request from the endpoint device, the system reads the first file list and the second file list, replaces files marked as suspect in the second file list with corresponding files in the first file list that are not marked as suspect, and generates a candidate file list. In response to the restore request, the system sends the candidate file list to the endpoint device for file restoration based on the candidate file list. The method of claim 1 further comprises: Detecting whether a file marked as a suspicious file in the second file list has a related file; Detecting whether a corresponding related file in the first file list is not marked as a suspicious file; and Replacing the related file in the second file list with a corresponding related file in the first file list that is not marked as a suspicious file to generate the candidate file list. The method of claim 2, wherein the associated files are files based on one or more of the following: Files located in the same folder, files of related types, files with dependencies, and files modified during the same period. The method of claim 1 further comprises: Testing the endpoint device using the candidate file list to detect whether the file format of a corresponding file in the endpoint device is corrupted; if not, optimizing out one or more corresponding files from the candidate file list; and Performing file recovery based on the optimized candidate file list. The method of claim 1, wherein the determination of whether the file format is corrupted or suspicious is based on at least one of the following: Whether the file can be opened by any software application; Whether the file can be parsed by any file parser; and Whether the file content entropy is high. The method of claim 1, further comprising: Restoring the files in the snapshot to the endpoint device based on the candidate file list. The method of claim 1, further comprising: Restoring the files in the snapshot to a second endpoint device other than the endpoint device based on the candidate file list. The method of claim 1 further comprises: If a corresponding file in the second file list is marked as a suspicious file, receiving a third file list corresponding to the third snapshot; Merging files in the third file list that are not marked as suspicious files into the candidate file list to generate an updated candidate file list; and Sending the updated candidate file list to the endpoint device in response to the update request. The method of claim 1 further comprises: If a backup file obtained from the snapshot during restoration would overwrite a damaged file, first copying the damaged file to another folder. The method of claim 1, further comprising: Placing the backup file obtained from the snapshot in a folder different from the local damaged file. A system for restoring files based on multiple snapshots comprises: a processor; and a memory connected to the processor, the memory storing a plurality of instructions executable by the processor to perform the method according to any one of claims 1 to 10.