CN117708809A - Data recovery method, device, computing device cluster and storage medium - Google Patents

Abstract

Disclosed are a data recovery method, apparatus, computing device cluster and storage medium, the method comprising: generating a file infection record based on snapshots of the file system at a plurality of snapshot time points, thereby responding to a data recovery instruction, accurately acquiring recovery data comprising a first file which is not infected from at least one snapshot of the first file recorded in the file infection record at the snapshot time points based on the file infection record, and carrying out data recovery based on the recovery data.

Description

Data recovery method, device, computing device cluster and storage medium

This application claims priority to Chinese patent application No. 202211124047.X filed on September 15, 2022, with invention name “A data management method for ransomware”, the entire contents of which are incorporated by reference into this application.

Technical Field

The present application relates to the field of storage technology, and in particular to a data recovery method, device, computing device cluster and storage medium.

Background Art

With the development of science and technology, data security has gradually received more attention. Ransomware is a computer virus that threatens data security. It uses various encryption algorithms to attack files, making the infected files unable to be read and written normally.

Currently, file systems usually use snapshot technology to save copies of files at multiple historical time points. When data is found to be infected by a virus, the files in the file system can be restored based on the file copies corresponding to a certain safe historical time point.

However, ransomware is highly concealed and will continue to attack in the file system. Since the above technical solution can only restore the file system to a certain historical time point before the virus attack, the files generated during the continuous virus attack are difficult to recover, and the efficiency of data recovery is very low.

Summary of the invention

The embodiment of the present application provides a data recovery method, apparatus, computing device cluster and storage medium, which can improve the efficiency of data recovery. The technical solution is as follows:

In a first aspect, a data recovery method is provided, the method comprising:

Based on the multiple snapshots, a file infection record is generated, where the file infection record indicates a snapshot of the infected first file before the infection, wherein the snapshot is a snapshot of the file system or a snapshot of the directory, and each of the snapshots corresponds to a snapshot time point;

In response to a data recovery instruction, based on the file infection record, recovery data is obtained from at least one snapshot whose snapshot time point is no later than the infection time of the first file, and data recovery is performed based on the recovery data, wherein the recovery data includes an uninfected first file obtained from the snapshot before the infection.

The software of the storage system (such as the file system software) continuously performs snapshot operations on the file system (or directory) to generate multiple snapshots, and detects whether there are infected files by comparing the contents of these multiple snapshots. For an infected file, the snapshot generated before it is infected records the healthy data of the file (that is, normal data that has not been tampered with), while the snapshot generated after it is infected records the data of the file after infection. In the first aspect, the snapshot before the infection of the file is recorded by the file infection record. When the user wants to restore the infected file, the snapshot where the data of the file before infection is located can be directly located by reading the file infection record, and the data of the infected file can be restored using the found snapshot, thereby obtaining uninfected data. Through the above technical solution, the infection of the file can be efficiently recorded, so that the infected file can be accurately restored, effectively avoiding the data loss caused by snapshot rollback, and greatly improving the efficiency of data recovery.

In a possible implementation, the file infection record is generated based on multiple snapshots, including:

Based on a pair of snapshots at adjacent snapshot time points among the multiple snapshots, determining a difference between a snapshot at a later snapshot time point among the adjacent snapshot time points and a snapshot at a previous snapshot time point among the adjacent snapshot time points;

Performing infection detection on the difference to determine that the first file is an infected file;

In the file infection record, the first file is recorded as an infected file.

By determining the differences between snapshots at adjacent snapshot time points and the infection detection process, the infected first file can be accurately and real-time determined, and the snapshot before the infection that can be used to restore the first file is indicated in the file infection record to ensure that the infection status of the recorded file can support accurate recovery of the infected file.

In a possible implementation, performing infection detection on the difference to determine that the first file is an infected file includes:

The first file with a virus identifier in the file suffix is determined as an infected file.

In some embodiments, the virus infection method includes modifying the file suffix of the file. Based on this, by utilizing this feature of the virus infection method, the infected file can be quickly detected to improve the speed of infection detection.

In a possible implementation, performing infection detection on the difference to determine that the first file is an infected file includes:

The first file whose file feature changes is determined as an infected file, and the file feature is used to characterize the file.

In some embodiments, virus infection may cause changes in file characteristics of files. Based on this, by utilizing this characteristic of the virus infection method, infected files can be quickly detected to increase the speed of infection detection.

In a possible implementation manner, the difference includes: a newly added file or a modified file in a snapshot at a later snapshot time point among the adjacent snapshot time points relative to a snapshot at a previous snapshot time point among the adjacent snapshot time points.

Since the virus infects files by encrypting, modifying and deleting files, newly added files and modified files in the file system may be files infected by the virus. Therefore, by identifying newly added files or modified files, it is possible to preliminarily determine the changes that may be caused by virus infection, and then through subsequent infection detection, the infected files can be accurately determined.

In a possible implementation manner, the file infection record includes file metadata of the first file before infection.

In a possible implementation, based on the file infection record, obtaining recovery data from at least one snapshot whose snapshot time point is not later than the infection time of the first file includes:

Determining pre-infection file metadata of the first file from the file infection record;

An uninfected first file is obtained from a snapshot indicated by the file metadata of the first file before infection.

Through the above process, an uninfected file copy can be quickly obtained based on the recorded pre-infection file metadata, providing an efficient information retrieval method for the data recovery process, greatly improving the efficiency of data recovery.

In a possible implementation manner, the file infection record also records the file metadata of the first file after infection, and the file metadata of the first file before infection and the file metadata of the first file after infection are associated;

The step of determining the pre-infection file metadata of the first file from the file infection record includes:

Determining infected file metadata of the first file from the file infection record;

Based on the post-infection file metadata of the first file, the pre-infection file metadata of the first file is determined.

Through the above process, not only the pre-infection file metadata used to obtain a usable file copy is recorded, but also the post-infection file metadata that can indicate the infection time of the file is recorded, thereby providing a complete infection situation for subsequent data recovery at any time point, further improving the efficiency of data recovery.

In a possible implementation, in response to the data recovery instruction, based on the file infection record, obtaining recovery data from at least one snapshot whose snapshot time point is not later than the infection time of the first file, and performing data recovery based on the recovery data, includes:

In response to the data recovery instruction, generating a clone file system;

Based on the file infection record, the recovery data is obtained from at least one snapshot whose snapshot time point is not later than the infection time of the first file, and data recovery is performed in the clone file system based on the recovery data.

The clone file system refers to a complete and available copy of the file system at a specified time point.

By restoring data in a cloned file system, the impact of the data recovery process on normal services in the current file system can be eliminated, thereby ensuring the consistency of the file system.

In a possible implementation, the performing data recovery on the file system based on the recovery data includes:

The infected first file in the current file system is overwritten with the uninfected first file.

Through the above technical solution, the recovery process for infected files can be completed efficiently without manually determining the infected files from the saved snapshots. Data recovery can be performed directly based on the file infection records generated in near real time, which effectively shortens the time required for data recovery and reduces the data loss caused by data recovery, greatly improving the efficiency of data recovery.

In one possible implementation, the method further includes:

In the case that the first file has not been completely restored, in response to an access request for the first file, the uninfected first file in the snapshot before being infected is accessed.

Through the above technical solution, it is possible to provide smooth file access services for the front-end business system during data recovery in the server background. That is, accurate recovery of infected data can be achieved without the business system being aware of the recovery process.

In a possible implementation, the infection refers to infection by a ransomware virus.

In a second aspect, an embodiment of the present application provides a data recovery device, comprising at least one functional module, wherein the at least one functional module is used to implement the data recovery method involved in the aforementioned first aspect or any optional implementation manner of the first aspect.

In a third aspect, an embodiment of the present application provides a computing device cluster, comprising at least one computing device, each computing device comprising a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster implements the data recovery method involved in the aforementioned first aspect or any optional implementation method of the first aspect.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, the computer-readable storage medium is used to store at least one program code, the at least one program code is executed by a computing device cluster to implement the data recovery method involved in the aforementioned first aspect or any optional implementation of the first aspect. The storage medium includes but is not limited to volatile memory, such as random access memory, non-volatile memory, such as flash memory, hard disk drive (HDD), solid state drive (SSD).

In a fifth aspect, an embodiment of the present application provides a computer program product, which, when executed on a computing device cluster, enables the computing device cluster to implement the data recovery method involved in the first aspect or any optional implementation of the first aspect. The computer program product may be a software installation package, and when the aforementioned data recovery method needs to be implemented, the computer program product may be downloaded and executed on a computing device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of an implementation environment of a data recovery method provided in an embodiment of the present application;

FIG2 is a schematic diagram of a data recovery method provided in an embodiment of the present application;

FIG3 is a schematic diagram of the hardware structure of a computing device provided in an embodiment of the present application;

FIG4 is a flow chart of a data recovery method provided in an embodiment of the present application;

FIG5 is a functional schematic diagram of a file system provided in an embodiment of the present application;

FIG6 is a flow chart of another data recovery method provided in an embodiment of the present application;

FIG. 7 is a schematic diagram of the structure of a data recovery device provided in an embodiment of the present application.

DETAILED DESCRIPTION

The implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

The key terms and key concepts involved in this application are explained below.

A snapshot is a usable copy of a specified data set, which includes a mirror image (or image) of the data set at the snapshot time point. That is, a snapshot is equivalent to a copy of the data set it indicates at a certain point in time.

Ransomware is a computer virus that is mainly spread in the form of emails, program Trojans, web page Trojans, etc. Ransomware uses various encryption algorithms to encrypt files, making important files unreadable and critical data damaged. It is usually difficult for users to decrypt, and they need to obtain the private key for decryption.

Continuous data protection (CDP) technology is a method that can continuously capture and save data changes in a file system and save the changed data independently of the original data.

The present application provides a data recovery method for recovering data from a file system, which can effectively improve the efficiency of data recovery. The implementation environment involved in the present application is introduced below.

FIG1 is a schematic diagram of an implementation environment of a data recovery method provided in an embodiment of the present application. Referring to FIG1 , the implementation environment includes a file system 110 , a file system management terminal 120 , an application program 130 , and a virus program 140 .

Among them, the file system 110 is used to provide file services, and the file system 110 is used to manage multiple files. In some embodiments, the file system 110 is implemented based on a computing device cluster composed of at least one computing device. In some embodiments, the computing device cluster can be a server, a server cluster composed of multiple physical servers, or a distributed file system, or a cloud server cluster that provides cloud storage and cloud services, cloud databases, cloud computing, cloud functions, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), big data and artificial intelligence platforms and other basic cloud computing services, and this application does not limit this. In some embodiments, the computing device cluster is used to run a storage system, which is a system composed of various storage devices for storing programs and data, control components, and hardware and software for managing information scheduling. The file system is used to provide storage and organization of file data in the storage system to realize the function of managing multiple files in the storage system.

Among them, the file system management terminal 120 is used to manage the file system 110. In some embodiments, the file system management terminal 120 is used to send a data recovery instruction to the file system 110 so that the file system 110 performs data recovery. In some embodiments, the file system management terminal 120 is a terminal. A terminal refers to a type of device that has rich human-computer interaction methods, has the ability to access the Internet, is usually equipped with various operating systems, and has strong processing capabilities. In some embodiments, the types of the above-mentioned terminals include but are not limited to personal computers, smart phones, tablet computers, car terminals, etc. In some embodiments, the file system management terminal 120 is a client software that uses the file service provided by the file system 110. The file system management terminal 120 can be used to manage file partitions with access rights in the file system, and this application does not limit this.

The application 130 is an application using the file service provided by the file system 110, and can access files in the file system 110. In some embodiments, the access refers to reading or writing existing files in the file system, or writing new files in the file system. In some embodiments, the application 130 runs based on the business system on the upper layer of the file system, and multiple applications 130 run in the business system, which realize different business functions by using the file storage service provided by the file system 110.

Among them, the virus program 140 can tamper with the files in the file system 110 to infect normal files in the file system. In some embodiments, the file infection method can be: modifying, encrypting or deleting the original file; or writing other invalid files. In some embodiments, the virus program 140 can run in any node that accesses the file system. The node can be a virtual machine, container or any computing instance that accesses the file system. In other embodiments, the virus program 140 can run in the business system where the application 130 is located. In some embodiments, the program code of the virus program 140 is hidden in the web page accessed by the business system. During the process of the business system accessing the web page, the program code of the virus program 140 is downloaded to the business system for execution, thereby being able to invade the file system 110 accessed by the business system. In some embodiments, the virus refers to a ransomware virus, and being infected refers to being infected by a ransomware virus.

In some embodiments, the file system management terminal 120, the application program 130 and the virus program 140 can communicate with the file system 110 via a wireless or wired network.

In the embodiment of the present application, the file system 110 supports generating and saving snapshots, so that infected files in the file system can be restored based on the saved snapshots.

In some embodiments, the file system 110 may support any of the following backup features to generate snapshots for recovering infected files.

HyperSnap feature: A snapshot that supports this backup feature is a consistent file copy of the source file in the file system at a certain snapshot time point. The fully available copy contains a static image of the source file at the snapshot time point.

HyperClone feature: A file system that supports this backup feature can make a complete copy of the source file in the file system at a certain point in time, or provide an incremental synchronization backup method. "Complete" means that the source file is completely copied to generate a file copy; "Incremental synchronization" means that the file copy can dynamically synchronize the changed parts of the source file.

The high-density continuous data protection (HyperCDP) feature supports snapshots of this backup feature in the same way as the high-density snapshot feature.

In some embodiments, the object of the snapshot may be a file system or a directory of the file system, and the present application does not limit the granularity of the snapshot. During the process of the virus program 140 continuously attacking the file system 110, the application program 130 and will also continuously access the file system 110, and the files generated in this process will be infected. The data recovery method provided in the embodiment of the present application can be applied to the above-mentioned file system 110 to perform accurate and efficient data recovery.

Based on the above introduction to the implementation environment, an embodiment of the present application provides a schematic diagram of a data recovery method, see Figure 2, wherein the snapshot at the snapshot time point T0 before the virus attack includes a directory of files such as "/document/1.doc; /document/10.doc"; during the continuous virus attack and normal business operation, the snapshot at the snapshot time point T1 records the files "/document/a.txt; /document/d.txt" operated normally by the application and the infected files "/document/1.doc; /document/10.doc"; the snapshot at the snapshot time point T2 records the files "/document/1.txt; /document/10.txt" operated normally by the application and the infected files "/document/a.txt; /document/b.txt"; the same is true for the snapshot time point Tn; the data recovery method provided in the embodiment of the present application can determine the infected files through infection detection, thereby accurately recovering the infected files. The detailed recovery process is described later and will not be repeated here. Wherein, n is a positive integer, and n is a sequential number of a snapshot time point. For ease of understanding, an example of snapshots at adjacent snapshot time points is shown below in conjunction with FIG. 2 , as shown in Table 1. In Table 1, “/document/” is abbreviated as “/doc/”, and “/picture/” is abbreviated as “/pic/”. “…” in Table 1 indicates omission.

Table 1

The computing device involved in the present application includes the above-mentioned server and terminal, and the computing device has a communication function and can access a wired network or a wireless network. In some embodiments, the wireless network or the wired network uses standard communication technology and/or protocol. The network includes but is not limited to any combination of a data center network, a storage area network (SAN), a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a mobile, wired or wireless network, a private network or a virtual private network. In some implementations, the data exchanged through the network is represented by the technology and/or format including hypertext markup language (HTML), extensible markup language (XML), etc. In addition, conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), virtual private network (VPN), and Internet protocol security (IPsec) can be used to encrypt all or part of the links. In other embodiments, customized and/or dedicated data communication technologies can be used to replace or supplement the above-mentioned data communication technologies.

An embodiment of the present application provides a computing device cluster. The computing device cluster includes one or more computing devices, and the computing device cluster can run the above-mentioned file system. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop, a laptop or a smart phone. In some embodiments, one or more computing devices in the computing device cluster can be connected via a network. The hardware structure of the computing device in the computing device cluster is introduced below.

The embodiment of the present application provides a computing device, which can be implemented as the above-mentioned server or terminal. Schematically, refer to Figure 3, which is a schematic diagram of the hardware structure of a computing device provided by an embodiment of the present application. As shown in Figure 3, the computing device 300 includes a memory 301, a processor 302, a communication interface 303 and a bus 304. Among them, the memory 301, the processor 302, and the communication interface 303 are connected to each other through the bus 304.

The memory 301 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The processor 302 implements the data recovery method in the following embodiments by reading the program code stored in the memory 301, or the processor 302 implements the data recovery method in the following embodiments by the program code stored internally. When the processor 302 implements the data recovery method in the following embodiment by reading the program code stored in the memory 301, the program code for implementing the data recovery method provided in the embodiment of the present application can be stored in the memory 301. The memory 301 can also store data such as file metadata, which is not limited in the embodiment of the present application.

The processor 302 may be a network processor (NP), a central processing unit (CPU), an application-specific integrated circuit (ASIC), or an integrated circuit for controlling the execution of the program of the present application. The processor 302 may be a single-CPU processor or a multi-CPU processor. The number of processors 302 may be one or more. The communication interface 303 uses a transceiver module such as a transceiver to implement communication between the computing device 300 and other devices or communication networks. For example, data may be acquired through the communication interface 303.

The memory 301 and the processor 302 may be separately provided or integrated together.

Bus 304 may include a path for transmitting information between various components of computing device 300 (eg, memory 301 , processor 302 , communication interface 303 ).

Based on the above implementation environment, during the process of the virus program continuously attacking the files stored in the file system, the application program in the upper-level business system will still access the file system, for example, deleting, modifying or writing new files to uninfected files. Therefore, during the continuous attack, the file system actually contains normal files and infected files. In the related art, the method of directly rolling back the file system to a certain snapshot time point will cause the normal files generated during the continuous virus attack to be unable to be restored. For example, see Table 1: (1) At the snapshot time point T0, the files "1.doc" and "10.doc", "a.txt", "d.txt", "a.bmp" and "d.bmp" have not been infected, (2) Between T0 and T1, some files in the file system are modified by normal access by the application program, and some files are modified because of the virus attack. Therefore, in the snapshot generated at the snapshot time point T1: the files "1.doc" and "10.doc" are infected by the virus program, while the files "a.txt" and "d.txt" are compared to T0. (3) Between T1 and T2, "a.txt" and "d.txt" remain infected ("a.txt" and "d.txt" are infected files, which are difficult to be accessed by applications normally, so they usually do not change and remain infected). New infected files "1.doc" and "10.doc" are added. Therefore, when taking a snapshot at T2, the snapshot files include 4 infected files, namely "a.txt", "d.txt", "1.doc" and "10.doc". At this time, if the relevant technology is used to directly roll back the file system to the snapshot time point T0, the operation results of the files "a.txt" and "d.txt" at T1 will be directly lost, and the modifications to the files "a.bmp" and "b.bmp" at Tn will also be lost; if the file system is directly rolled back to T1, the restored file system contains the infected files, and the effect of clearing the infection is not achieved. Similarly, when the file system is rolled back to a certain time, in addition to the modification, other normal operations on the files (including file deletion and new file writing) will also be lost. It can be seen that the relevant technology will cause data loss, making the efficiency of data recovery very low.

In view of this, the present application provides a data recovery method, which can accurately and efficiently recover data in the case where viruses continuously attack the file system, thereby greatly improving the efficiency of data recovery. The data recovery method provided by the present application is introduced below.

Figure 4 is a flow chart of a data recovery method provided by an embodiment of the present application. As shown in Figure 4, the data recovery method can be applied to the implementation environment shown in Figure 1 above, and is executed by a server running a file system. The data recovery method includes the following steps 401 to 404.

401. The server generates a file infection record based on multiple snapshots, where the file infection record indicates a snapshot of the infected first file before the infection, wherein the snapshot is a snapshot of a file system or a snapshot of a directory, and each snapshot corresponds to a snapshot time point.

In each embodiment provided in the present application, the object of the snapshot may be a file system (that is, all directories managed by the file system) or an individual directory in the file system. The present application does not limit the granularity of the snapshot.

In some embodiments, when there are multiple snapshots before the infected first file is infected, the file infection record may indicate any one of the multiple snapshots, or indicate a snapshot of the multiple snapshots that is closest to the infection time (ie, the latest one).

The storage system regularly takes snapshots of files in the file system, which is equivalent to regular data protection. When the storage system fails, the data is "rolled back" to the data at the snapshot time to avoid massive data loss.

In the embodiment of the present application, a snapshot is a usable copy of a file system at the snapshot time point. It should be noted that the object of the snapshot in the present embodiment is the file system, that is, a snapshot is taken of all files managed by the file. In other embodiments, the scope of the snapshot can be narrowed, for example, only a snapshot is taken of one or more directories. Since the principles of file system snapshots and directory snapshots are the same, only the file system is used as an example for description.

In some embodiments, the snapshot is a snapshot of a file in the file system. In this example, the snapshot includes a backup of the file at the corresponding snapshot time point and the file's metadata, wherein the file's metadata is used to obtain the backup of the specified file at the snapshot time point from the snapshot. In some embodiments, the metadata is used to describe the storage status of the file in the file system at the snapshot time point, for example, the metadata includes information such as the file name, the file suffix, and the data block where the file is located.

In other embodiments, the snapshot is for a directory of a file system. In this example, the snapshot includes the directory of the file system at the snapshot time point, and the directories at all levels of the file system constitute the path to access the file, so the directory recorded by the snapshot can indicate the status of each file and folder in the file system at the snapshot time point. In some embodiments, the directory of the file system can be stored in the form of a directory file, and a snapshot of the directory of the file system can be generated by copying the directory file of the file system at the snapshot time point.

In some embodiments, multiple snapshots of the file system can be stored in a storage space that does not interfere with the files, for example, a snapshot folder under the root directory of the file system for storing snapshots. In some embodiments, by accessing the storage space, the snapshots of the file system can be quickly accessed.

In an embodiment of the present application, snapshots stored periodically in the file system are used to back up files at different time points, so that in most cases, available historical copies of files before being attacked by viruses can be saved in time to achieve continuous data protection of the file system.

In an embodiment of the present application, the server compares the multiple snapshots to determine the differences between the snapshots, and then performs infection detection on the differences to determine the infected files in the file system to generate a file infection record.

The file infection record is used to perform data recovery on the file system. In an embodiment of the present application, the file infection record indicates a snapshot of the infected first file before it was infected. Based on this, during data recovery, the first file can be accurately restored to its state before it was infected according to the file infection record. In some embodiments, the first file can be an ordinary data file or other types of files such as a directory file, which is not limited in the present application.

In some embodiments, the process of the server generating the file infection record based on multiple snapshots may include the following steps 1 to 3.

Step 1: The server determines the difference between a snapshot at a later snapshot time point in a pair of adjacent snapshot time points in the plurality of snapshots and a snapshot at a previous snapshot time point in the pair of adjacent snapshot time points.

A pair of adjacent snapshot time points refers to two adjacent snapshot time points. For example, if the server generates a snapshot every 30 minutes, the snapshot time points 10:30 and 11:00 are a pair of adjacent snapshot time points.

In some embodiments, the server periodically generates snapshots of the file system. Exemplarily, the server generates a snapshot of the file system at target intervals. In some embodiments, the target duration between adjacent snapshot time points can be set according to business needs. For example, the target duration can be half an hour, one hour, or one day, etc., which is not limited in this application. In some embodiments, the server can perform this step 1 when the load meets the idle condition. For example, the server performs this step 1 when the kernel CPU usage is less than the idle threshold (such as 70%).

In some embodiments, after generating a snapshot, the server will compare snapshots in real time. In this example, each time the server generates a snapshot, it compares the latest snapshot with the previous snapshot to determine the difference between the snapshots. Based on this, the real-time nature of generating file infection records can be improved. In other embodiments, the server compares each pair of snapshots at adjacent time points in the multiple snapshots generated within the period of time at regular intervals, according to the order of the snapshot time points, to determine the difference between each pair of snapshots at adjacent time points. Based on this, the computing load of the server can be reduced.

In the embodiment of the present application, the difference indicates the change that occurs in the snapshot at the latter snapshot time point compared to the snapshot at the former snapshot time point. The change may be a file, file metadata, or a directory of the file system. The present application does not limit the granularity of the determined difference. The following introduces several situations in which the difference is determined in step 1, see the following situation 1, situation 2, and situation 3.

Case 1: The difference is a newly added file.

In some embodiments, the server compares the snapshots at the adjacent snapshot time points to determine the newly added files in the snapshot at the latter snapshot time point relative to the snapshot at the previous snapshot time point, and the newly added files are the differences between the snapshots at the adjacent snapshot time points. In some embodiments, the snapshot is a snapshot of a directory of a file system. The server compares the directories of the file system included in the snapshots at the adjacent snapshot time points to determine the newly added folders or files in the snapshot at the latter snapshot time point, thereby determining the newly added files.

Case 2: The difference is the modified file.

In some embodiments, the server compares the snapshots at the adjacent snapshot time points to determine the modified files in the snapshot at the latter snapshot time point relative to the snapshot at the previous snapshot time point, and the modified files are the differences between the snapshots at the adjacent snapshot time points. In some embodiments, the server compares the file metadata included in the snapshots at the adjacent snapshot time points to determine the modified files in the snapshot at the latter snapshot time point. For example, the file metadata includes the most recent modification time of the file and the size of the occupied space, etc. By comparing the snapshots at the adjacent snapshot time points, it can be determined that a certain file has been modified, thereby determining the modified file.

Since the virus infects files by encrypting, modifying and deleting files, newly added files and modified files in the file system may be files infected by the virus. Therefore, by identifying newly added files or modified files, it is possible to preliminarily determine the changes that may be caused by virus infection, and then through subsequent infection detection, the infected files can be accurately determined.

Case 3: The difference is file metadata.

In some embodiments, the server compares the snapshots at the adjacent snapshot time points to determine the file metadata that has changed in the snapshot at the latter snapshot time point relative to the snapshot at the former snapshot time point. Exemplarily, the changed file metadata may be a file suffix or a file name, etc. Based on this, it is possible to detect changes that may be caused by virus infection at the granularity of metadata, to preliminarily determine changes that may be caused by virus infection, and then accurately determine the infected files through infection detection.

Step 2: The server performs infection detection on the difference to determine that the first file is an infected file.

The infection detection refers to the process of detecting whether a file is infected. In some embodiments, the infection detection refers to determining whether the file indicated by the difference is infected according to the infection mode of any virus on the file.

In some embodiments, virus infection may cause a file feature to change. In this example, the server may determine the first file whose file feature changes as an infected file, wherein the file feature is used to characterize the file. In some embodiments, the file feature may be obtained by analyzing the state of the file, for example, whether the file is in an encrypted state or not. Exemplarily, the file feature may be the information entropy of the file, and the size of the information entropy may characterize the randomness of the file, thereby indicating whether the file is in an encrypted state. It is understandable that the greater the randomness of the file, the greater the possibility of being encrypted.

In some embodiments, the virus is a ransomware virus, and the main way of infection of the ransomware virus is to encrypt files, or to tamper with files so that the files are inaccessible. For the case where the infected file is in an encrypted state, considering that the randomness of the infected file in an encrypted state will be greatly enhanced, therefore, the infection detection can be to determine whether the file is encrypted based on the information entropy of the file, thereby determining whether the file is infected. In this example, the process of performing infection detection on the difference may include: the server determines the information entropy of the first file included in the difference; the server detects that the information entropy of the first file exceeds the information entropy interval of the file system, and determines that the first file is an infected file. Among them, the information entropy of the first file exceeds the information entropy interval means: exceeding the upper limit of the information entropy interval.

The above technical solution takes into account that virus infection may cause changes in the file characteristics of files. Based on this, by utilizing this characteristic of the virus infection method, infected files can be quickly detected to improve the speed of infection detection.

In some embodiments, a reasonable information entropy range of the file system can be determined by sampling and testing files in the file system. For example, the information entropy range can be expressed as: [H(LOW), H(HIGH)], where H(LOW) is the lower limit of the information entropy and H(HIGH) is the upper limit of the information entropy.

In some embodiments, the sampling detection can be performed on files that are updated in real time in the file system, thereby ensuring that the information entropy interval is dynamically updated as the business files in the file system are changed. In this example, the process of determining a reasonable information entropy interval includes: the server samples the files in the file system multiple times at each sampling interval to obtain multiple batches of sampled files; based on the information entropy of the multiple batches of sampled files, multiple reference entropy value intervals are determined; based on the multiple reference entropy value intervals, the information entropy interval of the file system is determined.

In other embodiments, considering that some files stored in the file system are encrypted files themselves, the sampling detection can also be performed on some early files of the file system to ensure that the information entropy range of the file system conforms to the original file storage characteristics of the file system.

The above technical solution can effectively improve the accuracy of infection detection and its applicability to file systems.

In other embodiments, the ransomware infection method includes modifying the file suffix of the file. In this example, the server can determine the first file with a virus identifier in the file suffix as an infected file. In some embodiments, the virus identifier can be a special suffix indicating a ransomware virus, such as ".lock" or ".encrypt".

In some other embodiments, the difference detected in step 1 includes file metadata. The server detects whether there is a virus identifier in the file suffix included in the file metadata of the first file included in the difference; if the virus identifier exists, and the first file with the same file name is also included in the snapshot at the previous snapshot time point in the adjacent snapshot time point, it can be determined that the first file has been infected at the next snapshot time point in the adjacent snapshot time point.

The above technical solution takes into account that the virus infection method includes modifying the file suffix of the file. Based on this, by utilizing this feature of the virus infection method, the infected file can be quickly detected to improve the speed of infection detection.

Step 3: The server records the first file as an infected file in the file infection record.

In the embodiment of the present application, through the above steps 1 to 2, it can be determined that the first file is infected, and the first file has not been infected in the snapshot at the previous snapshot time point, but has been infected in the snapshot at the next snapshot time point. Therefore, by indicating the snapshot before the first file is infected in the file infection record, the first file can be accurately restored to the state before the infection according to the file infection record during data recovery.

In some embodiments, the server saves the file metadata of the first file in the snapshot before infection (pre-infection file metadata) in the file infection record. The pre-infection file metadata can be used to find the pre-infection snapshot, and then obtain the uninfected first file from the pre-infection snapshot.

In some embodiments, the server saves the file metadata of the first file in the snapshot before infection (pre-infection file metadata) and the file metadata of the first file in the snapshot after infection (post-infection file metadata) in the file infection record. The post-infection file metadata can indicate at which snapshot time point the first file has been infected; the pre-infection file metadata can indicate at which snapshot time point the first file has not been infected.

In some embodiments, since it can be determined that the first file is infected in the time period between adjacent snapshot time points, therefore, when the system's recovery accuracy meets certain requirements, for example, the target duration for generating snapshots (that is, the interval between adjacent snapshot time points) is small enough, the file infection record can be close to the effect of recording the file infection in real time.

In some embodiments, the file metadata of the first file before infection and the file metadata of the first file after infection are associated. In some embodiments, the server detects the infected first file based on snapshots corresponding to a pair of adjacent snapshot time points, so that when generating a file infection record for this detection, a mapping relationship between the file metadata of the first file after infection and the file metadata before infection can be established in the file infection record, so that the file metadata after infection and the file metadata before infection are associated in this detection.

In some embodiments, the file infection record can be stored in the form of a file infection metadata database. The present application provides a schematic diagram of a file infection metadata database, see Table 2. In the file infection metadata database, there are recorded file infection records obtained by comparing multiple pairs of adjacent snapshot time points and infection detection, wherein T0 and T1 are a pair of adjacent snapshot time points; T1 and T2 are a pair of adjacent snapshot time points; taking the record obtained by comparing and detecting T0 and T1 as an example: the table records the file storage paths of the infected files "1.doc", "2.doc" and "3.doc.lock" at the time T1 under the snapshot corresponding to the time T1, and the file storage paths of the uninfected files corresponding to the infected files at the time T0 under the snapshot corresponding to the time T0. In Table 2, taking the file storage path included in the file metadata as an example, by storing the file storage paths under the corresponding snapshots before and after the file infection, it is ensured that the storage location of the file before and after the infection can be accurately known through the file infection record. In Table 2, "document/1.doc" under T1 and "document/1.doc" under T0 respectively indicate the storage location of the infected file "T1-1.doc" at time T1 and the storage location of the uninfected file "T0-1.doc" at time T0.

As shown in Table 2, the infected file "T1-3.doc.lock" has a virus mark in the file suffix, indicating that the virus at least uses the method of modifying the file suffix to tamper with the file "T0-3.doc". In this example, the server can detect the infected file "T1-3.doc.lock" by the aforementioned method of detecting virus marks; the infected file "T1-1.doc" does not have a virus mark in the file suffix, indicating that the virus may use other infection methods to tamper with the file "T0-1.doc", for example, encrypting the file content and modifying the file content to garbled code or ransom information. In this example, the server can detect the infected file "T1-1.doc" by the aforementioned method of calculating file information entropy. "..." in Table 2 indicates omission.

Table 2

Through the above steps 1 to 3, the infected first file can be accurately and nearly real-time determined by determining the difference between snapshots at adjacent snapshot time points and the infection detection process, and the snapshot before the infection that can be used to restore the first file is indicated in the file infection record. It can be understood that the above content is only introduced by taking the first file among the infected files as an example. In the implementation process, based on the above principles, multiple infected files may be detected for a pair of adjacent snapshot time points. Therefore, in the file infection record (item) corresponding to the pair of adjacent snapshot time points, file metadata corresponding to multiple infected files may be recorded. In other embodiments, the infected file may not be detected, and this application does not limit this.

In other embodiments, the server can provide a virus infection report to the file system management end based on the file infection record. In some embodiments, the virus infection report includes the detection results of infected files in the file system based on periodic snapshots, that is, which files are infected at which snapshot time points. Based on this, an alarm can be promptly sent to the file system management end so that the file system management end can initiate a data recovery process. In other embodiments, the file system management end can verify the accuracy of the above detection results based on the virus infection report, and feed back the verification results to the file system, thereby further improving the accuracy of the generated file infection record.

Based on the above description of step 401, the present application provides a functional schematic diagram of a file system based on the implementation environment provided by FIG. 1, see FIG. 5, wherein the file system includes multiple functional modules, and the file storage service module 501 is used to provide file services and snapshot services (supporting the aforementioned high-density snapshots, high-density cloning and other backup features), and can also cooperate with the data recovery module to realize data recovery; the infection detection module 502 is used to determine the infected files and generate file infection records, for example, executing the above steps 1 to 3; the data recovery module 503 is used to restore the file system based on the file infection record, for example, executing the following step 402; for more introductions to the file system, file system management terminal, application program and virus program in FIG. 5, please refer to the corresponding content of FIG. 1, which will not be repeated here.

402. In response to the data recovery instruction, the server obtains recovery data from at least one snapshot whose snapshot time point is no later than the infection time of the first file based on the file infection record, wherein the recovery data includes the uninfected first file obtained from the snapshot before the infection.

The data recovery instruction is used to instruct the file system to be recovered. In some embodiments, the data recovery instruction is sent by the file system management terminal, and in other embodiments, the data recovery instruction can also be sent by an application with management authority in the business system, which is not limited in this application.

The recovery data includes a file copy used to recover the infected file in the file system.

In some embodiments, the file infection record records the pre-infection file metadata of the first file (see the introduction in the aforementioned step 3), and the pre-infection snapshot corresponding to the pre-infection file metadata is a snapshot that is no later than the infection time of the first file. In this example, the server, in response to the data recovery instruction, can determine the pre-infection file metadata of the first file from the file infection record; and then obtain the uninfected first file (that is, the uninfected file copy) from the snapshot indicated by the pre-infection file metadata of the first file. Through the above process, the uninfected file copy can be quickly obtained based on the recorded pre-infection file metadata, providing an efficient information retrieval method for the data recovery process, greatly improving the efficiency of data recovery.

In other embodiments, the file infection record also records the file metadata of the first file after infection, and the file metadata of the first file before infection corresponds to the file metadata of the first file after infection (see the introduction in the aforementioned step 3). In this example, the process of the server determining the file metadata of the first file before infection from the file infection record includes: the server determines the file metadata of the first file after infection from the file infection record based on the data recovery instruction. Among them, the server reads the metadata of the first file after infection from the file infection record, and can determine the earliest snapshot time point recorded after the first file is infected, that is, the snapshot time point corresponding to the metadata after infection can be approximately used as the time point when the first file is infected. Based on this, the server can determine the file metadata of the first file before infection based on the file metadata after infection of the first file.

In some embodiments, the server can directly read the corresponding pre-infection file metadata from the file infection record based on the mapping relationship between the post-infection file metadata and the pre-infection file metadata. Through the above process, not only the pre-infection file metadata used to obtain the available file copy is recorded, but also the post-infection file metadata that can indicate the infection time of the file is recorded, thereby providing a complete infection situation for subsequent data recovery at any time point, further improving the efficiency of data recovery.

In some embodiments, the server can generate a file recovery task list based on the file infection record, and then obtain the recovery data of the file system from a snapshot before the first file was infected according to the file recovery task list.

In some embodiments, the task item in the file recovery task table indicates the infected file and the pre-infection file metadata of the infected file. In other embodiments, the file infection record records the post-infection file metadata of each infected file, and the snapshot time point corresponding to the post-infection file metadata can indicate the infection time of the infected file. Therefore, the server can sequentially scan the file infection records (items) corresponding to the infected files according to the order between the snapshot time points corresponding to the post-infection file metadata of each infected file, and generate the task item in the file recovery task table.

In some other embodiments, the server generates a clone file system in response to the data recovery instruction; and then obtains recovery data from at least one snapshot that is no later than the infection time of the first file based on the file infection record. This process is the same as the above-mentioned process of obtaining recovery data, and is not described in detail here. The clone file system refers to a complete and available copy of the file system at a specified time point.

In some embodiments, the server can implement the cloning process of the file system based on the aforementioned high-density cloning feature.

By restoring data in a cloned file system, the impact of the data recovery process on normal services in the current file system can be eliminated, thereby ensuring the consistency of the file system.

In other embodiments, if the data recovery instruction is for a target time point, that is, the data recovery instruction instructs to restore the file system to the state corresponding to the target time point. In this example, if the target time point is a snapshot time point, the server directly obtains the snapshot corresponding to the target time point, and determines the first file infected at the target time point based on the file infection record, and then obtains the recovery data for restoring the file system to the state of the target time point from at least one snapshot whose snapshot time point is not later than the infection time of the first file. If the target time point is not a snapshot time point, the server determines the snapshot time point closest to the target time point, and then performs the same process as above based on the snapshot time point to obtain the recovery data. The snapshot corresponding to the target time point includes uninfected files and the infected first file. Through the above process, the recovery data for accurately restoring the infected file can be obtained, thereby efficiently restoring the full amount of clean files of the file system at the target time point, greatly improving the efficiency of data recovery.

In some embodiments, the data recovery instruction can also indicate that the files or directories in the file system at the target time point are to be recovered. The present application does not limit the granularity of data recovery. In this example, the data recovery instruction can carry the file identifier (such as the file name) of the file to be recovered, or the directory to be recovered (such as the folder under the root directory) to accurately indicate the object to be recovered. In this example, the recovery data can include the directory file at the target time point. Based on this, a multi-granular recovery method is provided, which can be used to recover multiple granularities such as infected files, folders, and file systems, greatly improving the efficiency and flexibility of data recovery.

The above steps 401 to 402 describe the process of generating a file infection record and obtaining recovery data. A detailed example is provided below to illustrate the file infection and recovery process.

In some embodiments, the file system stores files based on an object storage structure. In the object storage structure, an object (object) may include a file and the file metadata of the file. Exemplarily, an object consists of an object key (key), an object value (value), and object metadata (metadata). The object key is the identifier of the object, which can be understood as the storage path of the file and can be used to find the file; the object value is also the content of the file (object content); the object metadata (metadata) includes the attribute information of the file, such as the modification time of the file, the file size, etc. Take the file system generating a snapshot every 1 hour as an example:

In the snapshot at 10 o'clock, the file "ABC.TXT" has not been infected. At this time, the file system uses object 1 as the object identifier of the file, and the file is presented as "ABC.TXT" in the directory of the file system. The object identifier points to the file "ABC.TXT".

In the snapshot at 11 o'clock, the suffix of the file "ABC.TXT" is changed to the ransomware suffix "LOCK", and the infected file appears as "ABC.LOCK" in the directory of the file system. At this time, a new object identifier object 2 (object 2) is used as the object identifier of the file inside the file system, and the file is infected.

In the 12 o'clock snapshot, since the file has been infected, it can no longer be correctly identified by the application and will no longer be modified by the application. At this time, the file is still presented as "ABC.LOCK" in the directory of the file system, and the object identifier inside the file system is still object 2.

The method provided in the embodiment of the present application can determine that the "ABC.TXT" has changed based on the snapshot at 10 o'clock and the snapshot at 11 o'clock through step 1, so that through step 2, the "ABC.LOCK" with the virus identifier "LOCK" in the file suffix is determined as an infected file, and then through step 3, in the file infection record corresponding to this detection, the file "ABC.TXT" is recorded as an infected file. In some embodiments, the snapshot at 10 o'clock can be indicated in the file infection record as the pre-infection snapshot of the file "ABC.TXT", and the snapshot at 11 o'clock can be indicated as the post-infection snapshot of the file "ABC.TXT". Exemplarily, the object metadata corresponding to object 1 can be recorded as the pre-infection file metadata, and the object metadata corresponding to object 2 can be recorded as the post-infection file metadata. Referring to Table 2 above, the file "ABC.TXT" in the snapshot at 10 o'clock is an uninfected file, and the file "ABC.LOCK" in the snapshot at 11 o'clock is an infected file.

Based on the snapshots at 11 o'clock and 12 o'clock, the file "ABC.LOCK" has not been changed, so the infection status of the file is not recorded again in the file infection record. The same applies to other snapshots after 12 o'clock, which will not be repeated here.

At a certain time after 12 o'clock, if the server receives a data recovery instruction indicating to recover the file "ABC.LOCK". Since the file can no longer be normally accessed by the application after being infected, all the contents of this file will remain unchanged (the corresponding metadata will also remain unchanged), that is, the contents at the time of infection will remain. Therefore, at the current moment, the file to be recovered in the file system is presented as "ABC.LOCK", and the file metadata of the file to be recovered is also the object metadata corresponding to object 2 (hereinafter referred to as "object 2"). Based on this, the server can determine the infected file metadata "object 2" stored in the file infection record according to the file metadata "object2" to be recovered. Since the file infection record records that object 2 has a corresponding relationship with object 1, the file metadata "object 1" before infection can be determined through "object 2", and then the corresponding uninfected file "ABC.TXT" can be directly obtained from the snapshot at 10 o'clock corresponding to "object 1" to accurately recover the data of the file "ABC.LOCK" at that certain time. To facilitate understanding of the above process, the present application provides an illustration of a pre-infection file metadata search process, see Table 3.

Table 3

In other embodiments, at a certain time after 12 o'clock, if the server receives a data recovery instruction for the file system, the file in the file system at this time is still presented as "ABC.LOCK". Based on this, the server can determine that the file "ABC.LOCK" is infected according to the infected file metadata "object 2" stored in the file infection record. Since the file infection record records that there is a mapping relationship between "object 2" and "object 1", object 1 can be found from object 2. Based on this, according to the stored pre-infection file metadata "object 1", the corresponding uninfected file "ABC.TXT" can be efficiently obtained from the snapshot at 10 o'clock, so as to accurately recover the data of the file "ABC.LOCK" at that certain time.

It should be noted that the above process is described by taking the infection method of modifying the file suffix as an example, and the embodiment of the present application does not limit the virus infection method.

403. The server performs data recovery based on the recovery data.

In some embodiments, based on the recovery data, the server may overwrite the infected first file in the current file system with the uninfected first file to implement a process of recovering the first file in the file system.

In some embodiments, the server obtains the uninfected first file by executing the task item corresponding to the first file in the above file recovery task table, thereby overwriting the infected first file in the current file system with the uninfected first file.

In some embodiments, the server performs data recovery on the file system based on the recovery data in a cloned file system of the current file system, and the recovery process is the same as described above.

Through the above technical solution, the recovery process for infected files can be completed efficiently without manually determining the infected files from the saved snapshots. Data recovery can be performed directly based on the file infection records generated in near real time, which effectively shortens the time required for data recovery and reduces the data loss caused by data recovery, greatly improving the efficiency of data recovery.

404. The server accesses the uninfected first file in the snapshot before infection in response to the access request for the first file.

This step 404 can be performed after the above step 401 is completed.

In some embodiments, the access request for the first file carries an identifier of the first file, for example, the file name of the first file. In some embodiments, the access request is sent by an application in a business system. In other embodiments, the access request may be for file metadata of the file, for example, a list of directories corresponding to the file, which is not limited in this application.

In some embodiments, the application running in the business system acts as a remote client and accesses the file system through the network. For example, the client can access the file system based on the network file system (NFS) technology or the common internet file system (CIFS) technology, which is not limited in this application.

In some embodiments, the access request may be sent to the server when the first file has not been fully restored, for example, step 403 has not been completed. When the first file has not been fully restored, the server accesses the uninfected first file in the snapshot before infection in response to the access request for the first file.

In some embodiments, in response to an access request for the first file, the server first determines from the file infection record whether the first file is infected, and then, if it is determined that the first file is an infected file, determines whether the first file has been recovered based on uncompleted task items in the file recovery task table of the server, and then, if the first file has not been recovered, access is made to the uninfected first file in the snapshot before infection based on the pre-infection file metadata of the first file. This process is also referred to as redirected access to the first file.

In other embodiments, when the first file has not been completely restored, the server can directly access the first file that has been completely restored in the current file system.

Through the above technical solution, it is possible to provide smooth file access services for the front-end business system during data recovery in the server background. That is, accurate recovery of infected data can be achieved without the business system being aware of the recovery process.

In other embodiments, a recovery status flag is set in the file system. When the server performs data recovery on the file system, for example, in response to a data recovery instruction, the server sets the recovery status flag of the file system to a pending recovery state, and the pending recovery state indicates that the file system is performing data recovery. In this example, in response to an access request for the first file, the server first detects the recovery status flag of the file system. If the recovery status flag of the file system is a pending recovery state, the above-mentioned determination of whether the first file is infected and whether the first file has been fully recovered is performed. If the recovery status flag of the file system is not a pending recovery state, the first file that has been fully recovered in the current file system can be directly accessed. By setting the recovery status flag, the access speed to the first file during the background data recovery process can be accelerated.

In the embodiment of the present application, the file system periodically takes snapshots of the file system (or directory), and the storage system periodically or in real time compares a pair of snapshots corresponding to a pair of adjacent front and rear snapshot time points (pre-infection snapshot and post-infection snapshot). If the difference in a pair of snapshots of the same file at adjacent snapshot time points meets the characteristics of being infected by the ransomware virus, it is determined that such a file is infected within the time range between the front and rear snapshot time points. Therefore, the uninfected snapshot (pre-infection snapshot) corresponding to the file is recorded with the file infection record, that is, the latest data of the file recorded in the pre-infection snapshot before being infected can be accurately recorded. When the user wants to recover the infected file, by reading the file infection record, the snapshot of the file recorded last time before the file was infected can be directly located, and the infected file can be accurately restored using the found pre-infection snapshot. Compared with the aforementioned related art, which selects snapshots at each snapshot time point and tries to recover them one by one until the latest snapshot before being infected is found, it can be seen that the data recovery method provided by the embodiment of the present application is more efficient.

Through the above technical solution, the infected file situation can be recorded efficiently, so as to accurately restore the infected file, effectively avoid the data loss caused by snapshot rollback, and greatly improve the efficiency of data recovery. Furthermore, it can generate file infection records in near real time based on the infection detection of periodically obtained file copies, and provide the details of the infected file to the user in the form of a virus infection report; and it provides near real-time data accurate recovery combining the front and back ends, which can provide clean and normally accessible files to applications or users in near real time, ensuring that the upper-level business system will not read the infected files or does not need to wait for the file recovery to be completed, greatly improving the flexibility and applicability of data recovery in various business scenarios.

The above process is described using a ransomware virus as an example. The data recovery method provided in the embodiment of the present application can also perform data recovery for files infected by other types of viruses, and the present application does not limit this.

Based on the embodiment corresponding to FIG. 4 and the function of the file system introduced in FIG. 5 , the present application provides a flowchart of another data recovery method, see FIG. 6 .

The data recovery method provided in the embodiment of the present application shown in Figure 6 includes a protection process, a detection process, a recovery process and an access process. The protection process, detection process, recovery process and access process are introduced below respectively.

Referring to Figure 6, the protection process in the data recovery method provided in the embodiment of the present application is executed by the file storage business module 501. The protection process refers to the file system generating snapshots at multiple snapshot time points, for example, snapshots at T0, T1 and T2. The protection capability indicates the ability of the file system to generate consistent copies, such as the high-density snapshots, high-density cloning and high-density continuous data protection features introduced above.

Referring to Figure 6, the detection process in the data recovery method provided in the embodiment of the present application is executed by the infection detection module 502. The detection process includes two parts: periodic infection detection and generating a virus infection report. Among them, the periodic infection detection includes: obtaining differences in the file system (refer to step 1); performing infection detection based on differences, and the infection detection includes detection based on information entropy (see step 2); determining infected files (see step 2). Generating a virus infection report includes: generating a file infection record (see step 3), and the file infection record example in Figure 6 is the above Table 2; sending a virus infection report to the file system management end (see step 3), wherein the file system management end can verify the file infection record.

6 , the recovery process in the data recovery method provided in the embodiment of the present application is executed by the data recovery module 503. The recovery process includes the following (1) to (3).

(1) Based on the target time point Tn indicated by the data recovery instruction, a clone file system is generated (see step 402).

(2) The recovery status flag of the file system is set to the pending recovery status Flag.

(3) Perform data recovery, including the following (3-1) to (3-3).

(3-1) The data recovery module determines the infected files in the file system from the file infection records and generates a file recovery task table.

(3-2) The data recovery control module executes the task item in the file recovery task table: overwriting the infected file with the pre-infection file.

(3-3) After the data recovery is completed, the pending recovery status Flag of the file system is cleared, and the file recovery task table is cleared.

6, the access process in the data recovery method provided in the embodiment of the present application is executed by the file storage service module 501. The file system management terminal initiates recovery of the file system, that is, while the file system performs data recovery based on the clone file system (generated at Tn), the upper-layer service system accesses the real-time (Tn+1) file system. At this time, the access process includes the following steps A and B.

Step A: An application program or any user in the upper-layer business system accesses data to the current file system based on NFS or CIFS;

Step B, check whether there is a flag of the state to be restored, if not, access the file to be accessed in the current file system normally; if yes, determine whether the file to be accessed is infected, and the determination process includes: query the file infection record to determine whether the file to be accessed is infected before Tn, if not, access the file to be accessed in the current file system normally; if infected, query the file recovery task table to determine whether the file to be accessed has been restored; if yes, support access to the file to be accessed in the current file system; if not, redirect access to the file before infection according to the file metadata before infection of the file to be accessed.

The implementation principles of each process in FIG. 6 above refer to the corresponding steps in the embodiment corresponding to FIG. 4 above, and are not described in detail here.

FIG7 is a schematic diagram of the structure of a data recovery device provided by an embodiment of the present application. As shown in FIG7, the data recovery device includes: a generation module 701, which is used to generate a file infection record based on multiple snapshots, wherein the file infection record indicates a snapshot of the infected first file before the infection, wherein the snapshot is a snapshot of a file system or a snapshot of a directory, and each of the snapshots corresponds to a snapshot time point;

The recovery module 702 is used to respond to the data recovery instruction, based on the file infection record, obtain recovery data from at least one snapshot whose snapshot time point is not later than the infection time of the first file, and perform data recovery based on the recovery data, wherein the recovery data includes the uninfected first file obtained from the snapshot before the infection.

In a possible implementation manner, the generating module 701 includes:

a difference determining unit, configured to determine, based on snapshots at a pair of adjacent snapshot time points among the plurality of snapshots, a difference between a snapshot at a later snapshot time point among the adjacent snapshot time points and a snapshot at a previous snapshot time point among the adjacent snapshot time points;

an infection detection unit, configured to perform infection detection on the difference to determine that the first file is an infected file;

The recording unit is used to record the first file as an infected file in the file infection record.

In a possible implementation manner, the infection detection unit is used to:

The first file with a virus identifier in the file suffix is determined as an infected file.

In a possible implementation manner, the infection detection unit is used to:

The first file whose file feature changes is determined as an infected file, and the file feature is used to characterize the file.

In a possible implementation manner, the difference includes: a newly added file or a modified file in a snapshot at a later snapshot time point among the adjacent snapshot time points relative to a snapshot at a previous snapshot time point among the adjacent snapshot time points.

In a possible implementation manner, the file infection record includes file metadata of the first file before infection.

In a possible implementation, the recovery module 702 includes:

A first determining unit, configured to determine the pre-infection file metadata of the first file from the file infection record;

The acquisition unit is used to acquire the uninfected first file from the snapshot indicated by the file metadata before the infection of the first file.

In a possible implementation manner, the file infection record also records the file metadata of the first file after infection, and the file metadata of the first file before infection and the file metadata of the first file after infection are associated; the first determining unit is used to:

Determining infected file metadata of the first file from the file infection record;

Based on the post-infection file metadata of the first file, the pre-infection file metadata of the first file is determined.

In a possible implementation, the recovery module 702 is used to:

In response to the data recovery instruction, generating a clone file system;

Based on the file infection record, the recovery data is obtained from at least one snapshot whose snapshot time point is not later than the infection time of the first file, and data recovery is performed in the clone file system based on the recovery data.

In a possible implementation, the recovery module 702 is used to:

The infected first file in the current file system is overwritten with the uninfected first file.

In one possible implementation, the device further includes:

The access module is used to access the uninfected first file in the snapshot before infection in response to an access request for the first file when the first file has not been completely restored.

In a possible implementation, the infection refers to infection by a ransomware virus.

Through the above device, the infected file situation can be efficiently recorded, so as to accurately restore the infected file, effectively avoid data loss caused by snapshot rollback, and greatly improve the efficiency of data recovery. Furthermore, it can generate file infection records in near real time based on the infection detection of periodically obtained file copies, and can provide users with details of infected files in the form of virus infection reports; and it provides near real-time data accurate recovery combining front-end and back-end, which can provide clean and normally accessible files to applications or users in near real time, ensuring that the upper-level business system will not read the infected files or does not need to wait for the file recovery to be completed, greatly improving the flexibility and applicability of data recovery in various business scenarios.

In addition, in the above data recovery device, the generation module 701 and the recovery module 702 can be implemented by software or hardware. Exemplarily, the generation module 701 is taken as an example to introduce the implementation of the generation module 701. Similarly, the implementation of the recovery module 702 and other modules can refer to the implementation of the generation module 701.

As an example of a software functional unit, the generation module 701 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned computing instance may be one or more. For example, the generation module 701 may include code running on multiple hosts/virtual machines/containers. It should be noted that the multiple hosts/virtual machines/containers used to run the code can be distributed in the same region (region) or in different regions. Furthermore, the multiple hosts/virtual machines/containers used to run the code can be distributed in the same availability zone (AZ) or in different AZs, each AZ including a data center or multiple data centers with similar geographical locations. Among them, usually a region can include multiple AZs.

Similarly, multiple hosts/virtual machines/containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

As an example of a hardware functional unit, the generation module 701 may include at least one computing device. Alternatively, the generation module 701 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

The multiple computing devices included in the generation module 701 can be distributed in the same region or in different regions. The multiple computing devices included in the generation module 701 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the generation module 701 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs. In addition, the data recovery device and the data recovery method embodiment provided in the above embodiment belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions. For example, the files and file metadata involved in this application are obtained with full authorization.

In this application, the words such as the term "first", "second", etc. are used to distinguish the same or similar items with substantially the same effects and functions. It should be understood that there is no logical or temporal dependency between "first", "second", and "nth", nor is the quantity and execution order limited. It should also be understood that although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by the terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of the various examples described, the first file can be referred to as the second file, and similarly, the second file can be referred to as the first file. Both the first file and the second file can be files, and in some cases, can be separate and different files.

The term "at least one" in this application means one or more, and the term "plurality" in this application means two or more, for example, a plurality of files means two or more files.

The above description is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of program structure information. The program structure information includes one or more program instructions. When the program instructions are loaded and executed on a computing device, all or part of the processes or functions in the embodiments of the present application are generated.

A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the aforementioned embodiments can still be modified, or some of the technical features therein can be replaced by equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims (27)

1. A method of data recovery, the method comprising:

generating a file infection record based on a plurality of snapshots, the file infection record indicating a snapshot of an infected first file before the infection, wherein the snapshots are snapshots of a file system or a directory, each snapshot corresponding to a snapshot time point;

and responding to a data recovery instruction, acquiring recovery data from at least one snapshot of which the snapshot time point is not later than the infection time of the first file based on the file infection record, and carrying out data recovery based on the recovery data, wherein the recovery data comprises an uninfected first file acquired from the snapshot before being infected.

2. The method of claim 1, wherein generating a file infection record based on the plurality of snapshots comprises:

determining a difference between a snapshot of a later snapshot time point of the adjacent snapshot time points and a snapshot of a previous snapshot time point of the adjacent snapshot time points based on snapshots of a pair of adjacent snapshot time points of the plurality of snapshots;

detecting the difference to determine that the first file is an infected file;

in the file infection record, the first file is recorded as an infected file.

3. The method of claim 2, wherein the detecting the difference to determine that the first file is an infected file comprises:

and determining the first file with the virus identifier in the file suffix as an infected file.

4. A method according to any one of claims 2 to 3, wherein said detecting the difference to determine that the first file is an infected file comprises:

and determining the first file with changed file characteristics as an infected file, wherein the file characteristics are used for representing the file.

5. The method of any one of claims 2 to 4, wherein the difference comprises: and newly added files or modified files in the snapshots of the later snapshot time point in the adjacent snapshot time points relative to the snapshots of the previous snapshot time point in the adjacent snapshot time points.

6. The method according to any one of claims 1 to 5, wherein in the file infection record, pre-infection file metadata of the first file is recorded.

7. The method of claim 6, wherein the obtaining recovery data from at least one snapshot of the snapshot time point that is no later than an infection time of the first file based on the file infection record comprises:

determining pre-infection file metadata of the first file from the file infection record;

and acquiring the first file which is not infected from the snapshot indicated by the file metadata before infection of the first file.

8. The method of claim 7, wherein in the file infection record, post-infection file metadata of the first file is also recorded, the pre-infection file metadata of the first file and post-infection file metadata of the first file being associated;

the determining, from the file infection record, pre-infection file metadata of the first file includes:

determining infected file metadata of the first file from the file infection record;

Based on the post-infection file metadata of the first file, pre-infection file metadata of the first file is determined.

9. The method according to any one of claims 1 to 8, wherein the obtaining, in response to a data recovery instruction, recovery data from at least one snapshot of the snapshot time point not later than an infection time of the first file based on the file infection record, performing data recovery based on the recovery data, includes:

generating a clone file system in response to the data recovery instruction;

and acquiring the recovery data from at least one snapshot of which the snapshot time point is not later than the infection time of the first file based on the file infection record, and performing data recovery based on the recovery data in the clone file system.

10. The method according to any one of claims 1 to 9, wherein the performing data recovery based on the recovery data comprises:

and covering the infected first file in the current file system by using the first file which is not infected.

11. The method according to any one of claims 1 to 10, further comprising:

And in the case that the first file is not restored to be completed, accessing the first file which is not infected in the snapshot before being infected in response to the access request for the first file.

12. The method according to any one of claims 1 to 11, wherein the infection is infection with the lux virus.

13. A data recovery apparatus, the apparatus comprising:

a generating module, configured to generate a file infection record based on a plurality of snapshots, where the file infection record indicates a snapshot of an infected first file before being infected, and the snapshot is a snapshot of a file system or a snapshot of a directory, and each snapshot corresponds to a snapshot time point;

and the recovery module is used for responding to a data recovery instruction, acquiring recovery data from at least one snapshot of which the snapshot time point is not later than the infection time of the first file based on the file infection record, and carrying out data recovery based on the recovery data, wherein the recovery data comprises an uninfected first file acquired from the snapshot before being infected.

14. The apparatus of claim 13, wherein the generating module comprises:

A difference determining unit configured to determine, based on snapshots of a pair of adjacent snapshot time points among the plurality of snapshots, a difference between a snapshot of a subsequent snapshot time point among the adjacent snapshot time points and a snapshot of a previous snapshot time point among the adjacent snapshot time points;

an infection detection unit configured to detect infection of the difference to determine that the first file is an infected file;

and the recording unit is used for recording the first file as an infected file in the file infection record.

15. The apparatus of claim 14, wherein the infection detection unit is configured to:

and determining the first file with the virus identifier in the file suffix as an infected file.

16. The apparatus according to any one of claims 14 to 15, wherein the infection detection unit is configured to:

and determining the first file with changed file characteristics as an infected file, wherein the file characteristics are used for representing the file.

17. The apparatus of any one of claims 14 to 16, wherein the difference comprises: and newly added files or modified files in the snapshots of the later snapshot time point in the adjacent snapshot time points relative to the snapshots of the previous snapshot time point in the adjacent snapshot time points.

18. The apparatus according to any one of claims 13 to 17, wherein in the file infection record, pre-infection file metadata of the first file is recorded.

19. The apparatus of claim 18, wherein the recovery module comprises:

a first determining unit configured to determine, from the file infection record, pre-infection file metadata of the first file;

and the acquisition unit is used for acquiring the first file which is not infected from the snapshot indicated by the file metadata before infection of the first file.

20. The apparatus of claim 19, wherein in the file infection record, post-infection file metadata of the first file is also recorded, the pre-infection file metadata of the first file and post-infection file metadata of the first file being associated; the first determining unit is configured to:

determining infected file metadata of the first file from the file infection record;

based on the post-infection file metadata of the first file, pre-infection file metadata of the first file is determined.

21. The apparatus according to any one of claims 13 to 20, wherein the recovery module is configured to:

Generating a clone file system in response to the data recovery instruction;

and acquiring the recovery data from at least one snapshot of which the snapshot time point is not later than the infection time of the first file based on the file infection record, and performing data recovery based on the recovery data in the clone file system.

22. The apparatus of any one of claims 13 to 21, wherein the recovery module is configured to:

and covering the infected first file in the current file system by using the first file which is not infected.

23. The apparatus according to any one of claims 13 to 22, further comprising:

and the access module is used for responding to the access request for the first file and accessing the first file which is not infected in the snapshot before being infected under the condition that the first file is not restored to be completed.

24. A device according to any one of claims 13 to 23, wherein the infection is infection with the lux virus.

25. A cluster of computing devices, comprising at least one computing device, each computing device comprising a processor and a memory;

The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the data recovery method of any one of claims 1 to 12.

26. A computer readable storage medium for storing a program code for performing the data recovery method according to any one of claims 1 to 12.

27. A computer program product, characterized in that the computer program product, when run on a computing device, causes the computing device to perform the data recovery method of any of claims 1 to 12.