WO2021052231A1

WO2021052231A1 - Data detection method and device

Info

Publication number: WO2021052231A1
Application number: PCT/CN2020/114350
Authority: WO
Inventors: 李永辉; 侯杰
Original assignee: 华为技术有限公司
Priority date: 2019-09-19
Filing date: 2020-09-10
Publication date: 2021-03-25
Also published as: CN110674502A

Abstract

A data detection method and device. The method comprises: upon generating first snapshot data of a first moment, acquiring data in a first disaster recovery array, the data in the first disaster recovery array comprising the first snapshot data (101); performing detection on the data in the first disaster recovery array to obtain a first detection result (102); and generating, according to the first detection result, a detection report on the first snapshot data (103). The method can be used to perform real-time detection on file data backed up in a disaster recovery array upon generating snapshot data corresponding to a local disk array at any time, so as to immediately detect whether data at a recovery point has changed after generating the recovery point, thereby helping users quickly locate a target recovery point, and preventing the users from blindly and tentatively searching for the target recovery point and thus wasting a lot of time.

Description

Data detection method and device

Technical field

This application relates to the field of data storage, and in particular to a data detection method and device in the CDP system.

Background technique

Continuous data protection (CDP) is a method that continuously captures or tracks any changes in target data without affecting the operation of the main data, and can be restored to any previous point in time. The CDP system can provide block-level, file-level, and application-level backups, as well as unlimited and arbitrary variable recovery points for recovery targets.

CDP technology captures all file access operations in real time by implanting file filtering drivers, such as IoSplitter, in the core layer of the operating system. For files that require continuous CDP backup protection, when the CDP management module intercepts the rewriting operation through the file filter driver, it will automatically back up the file data changes together with the current system time stamp to the storage device in advance, such as Snapshot disk. In theory, any file data change will be automatically recorded, so it is called continuous data protection. The CDP can achieve the second-level Recovery Point Objective (RPO) and Recovery Time Objective (RTO), that is, the snapshot data backed up by the CPD reaches the interval of several seconds, and each recovery point Corresponding to a snapshot disk or storage array, the abundant recovery points in the CDP system ensure that users can recover from any disaster scenario with minimal data loss.

However, when users are faced with too many recovery points, they can also be troubled. For example, when the system is infected by a ransomware virus, some files are encrypted and cannot be accessed, but the operating system can still operate normally. At this time, when the user notices this situation, it may be several hours after the ransomware infects the system files. Up. Therefore, when a user wants to restore data, because the second-level RPO of the CPD system will generate tens or even hundreds of recovery points within a few hours, the user wants to find the last recovery point before being infected by the virus (that is, the target recovery point). Point) will become difficult, in which data recovery at the target recovery point can eliminate the virus and also lose the least data.

The general search method is that the CDP system pushes all the recovery points generated within a few hours to the user. The user tries to recover the data from the recovery point that he thinks may obtain healthy data. Once the healthy data cannot be obtained, the next recovery point Continue to do data recovery until you get healthy data at a certain recovery point. In this process, the user may have to try N recovery points before determining the target recovery point. As a result, the actual time for the CDP system to find the target recovery point is N times the RTO promised to the user, and the detection of the expected time cannot be fulfilled. And restore the promise of data.

Summary of the invention

The embodiment of the present application provides a method for detecting recovery point data, which is used to solve the blind and time-consuming problem of the existing recovery point search process. In order to solve the technical problem, the embodiment of the present application specifically discloses the following technical solutions :

In the first aspect, an embodiment of the present application provides a data detection method, which may be executed by a data analysis module. Specifically, the method includes: when generating the first snapshot data at the first moment, acquiring the first disaster Data in the backup array, the data in the first disaster recovery array includes the first snapshot data; detecting the data in the first disaster recovery array to obtain a first detection result, and according to the first detection result A detection report of the first snapshot data is generated.

In the method provided in this aspect, when the disaster recovery center generates the snapshot data corresponding to the local disk array at any time, it detects the file data backed up in the disaster recovery array in real time, so as to check whether the data at the recovery point is immediately after the recovery point is generated. When changes occur, a test report is generated for the change and test results and displayed to the user. When the user checks the recovery point or wants to recover the data at a certain time, the target recovery point can be determined only by the file change shown in the detection report generated in real time, so as to quickly restore the data at the target recovery point. It achieves the effect of what users see is what you get, and avoids users from blindly and experimentally finding the target recovery point, which will consume a lot of time.

With reference to the first aspect, in a possible implementation of the first aspect, detecting data in the first disaster recovery array includes: performing a first layer detection on the data in the first disaster recovery array, The first layer detection includes detecting whether the block device where the data of the first disaster recovery array is changed; if there is no change, the second layer detection is performed, and the second layer detection includes checking the block device Files to be detected.

Wherein, the block device includes devices such as logical unit LUNs, volumes, or disks.

Further, when the block device of the snapshot data changes during the first-level detection, the second-level detection is stopped, and the detection result of the first-level detection is directly reported, and a detection report is generated. When the first-level detection has not changed, the second-level detection is performed, and the changes of all files detected in the second-level are counted and summarized, and the corresponding detection report is generated.

With reference to the first aspect, in another possible implementation of the first aspect, the file includes at least one of a file system log file, an operating system configuration file, and an operating system log file.

Further, detecting the file includes:

The detection of the file system log files specifically includes: reading each of the file system log files, and analyzing the addition, deletion, and modification of each log file.

Detecting the operating system configuration files specifically includes: reading each operating system configuration file, analyzing each configuration file, comparing it with the key configuration file at the previous moment, and obtaining changes in each configuration file Wait.

Detecting the operating system log files specifically includes: reading each operating system log file, analyzing each log file, obtaining a log recorded as an error or warning in the log file, and recording the error Or warning log.

This implementation method detects the data of the disaster recovery array layer by layer, and the detection categories range from block devices, such as disks, partitions, and volumes, to file systems in block devices, such as file system log files, operating system configuration files, and operating systems. The detailed detection of log files can achieve fine-grained health detection of the snapshot data in the disaster recovery array to the file level, specific to each file, so it can report to the user the changes in the disaster recovery array of each time stamp through the detection report, which is convenient The user quickly determines the best recovery point for recovery.

With reference to the first aspect, in yet another possible implementation of the first aspect, the first snapshot data further includes application data generated by at least one application; the method further includes: using a third-party program to compare the at least one application to the at least one application. The addition, deletion, and modification of application data generated by an application are detected.

In this implementation method, when detecting the application data (or strong background data) generated by the application, the virtual machine system is pulled up on the snapshot disk at a certain moment, and the third-party application is dependent on the virtual machine system. Run and analyze the application log files, and record the detection results, thereby realizing the detection of application data, generating modification records containing the log files of a specific application, and helping users determine the best recovery point before the object is modified.

In a second aspect, an embodiment of the present application provides a data detection device. The device includes an acquisition unit and a processing unit. The acquisition unit is configured to acquire the first disaster recovery array when generating the first snapshot data at the first moment. The data in the first disaster recovery array includes the first snapshot data; the processing unit is configured to detect the data in the first disaster recovery array to obtain a first detection result, and according to the first A detection report of the first snapshot data is generated as a result of the detection.

With reference to the second aspect, in a possible implementation of the second aspect, the processing unit is specifically configured to perform a first layer detection on the data in the first disaster recovery array, and the first layer detection includes detection Whether the block device where the data of the first disaster recovery array is located has changed; if there is no change, a second layer detection is performed, and the second layer detection includes detection of files in the block device.

Optionally, the file includes at least one of a file system log file, an operating system configuration file, and an operating system log file.

With reference to the second aspect, in another possible implementation of the second aspect, the first snapshot data further includes application data generated by at least one application; the processing unit is further configured to use a third-party program to The addition, deletion, and modification of application data generated by the at least one application are detected.

In a third aspect, an embodiment of the present application also provides a communication device. The communication device includes a processor, the controller is coupled to a memory, and the memory is used for storing instructions; and the controller is used for executing instructions in the memory. The instructions for causing the communication device to execute the foregoing first aspect and the methods in various implementation manners of the first aspect.

In a fourth aspect, the embodiments of the present application also provide a computer-readable storage medium. The storage medium stores instructions. When the instructions run on a computer or a processor, they are used to execute the aforementioned first aspect and the first aspect. On the one hand, the methods in various implementations.

In the fifth aspect, the embodiments of the present application also provide a computer program product. The computer program product includes computer instructions. When the instructions are executed by a computer or a processor, the foregoing first aspect and various aspects of the first aspect can be implemented. The method in the implementation mode.

In a sixth aspect, an embodiment of the present application also provides a chip system, the chip system includes a processor and an interface circuit, the interface circuit is coupled with the processor, and the processor is used to execute computer programs or instructions to The foregoing first aspect and the methods in the various implementation manners of the first aspect are implemented; the interface circuit is used to communicate with modules other than the chip system.

In the method provided in this embodiment, the CDP system performs real-time detection of the file data backed up in the disaster recovery array when the file on the local disk generates the corresponding snapshot data, so as to check the data, partitions, and partitions of the recovery point immediately after the recovery point is generated. Whether the disk, volume, various files, etc. have changed, and generate a test report for the change and test results, and display it to the user.

Since this method performs file-level health detection on the snapshot data in the disaster recovery array, it is detailed to each specific file, so when the system has a virus intrusion, it can reflect the changes of the disaster recovery array at two moments before and after. When the user checks the recovery point or wants to recover the data at a certain time, the target recovery point can be determined only by the file change shown in the detection report generated in real time, so as to quickly restore the data at the target recovery point to achieve In order to avoid the user from blindly and experimentally searching for the target recovery point, the user sees is what they get, which causes a lot of time-consuming.

Description of the drawings

FIG. 1 is a schematic structural diagram of a continuous data protection CDP system provided by an embodiment of this application;

2 is a schematic structural diagram of a storage array or disaster recovery array provided by an embodiment of the application;

FIG. 3 is a schematic structural diagram of another CDP system provided by an embodiment of this application;

FIG. 4 is a flowchart of a data detection method provided by an embodiment of the application;

FIG. 5 is a schematic diagram of a weak data detection process provided by an embodiment of the application;

FIG. 6 is a schematic diagram of a strong data detection process provided by an embodiment of this application;

FIG. 7 is a schematic structural diagram of a data detection device provided by an embodiment of the application;

FIG. 8 is a schematic structural diagram of another disaster recovery array provided by an embodiment of the application.

detailed description

In order to enable those skilled in the art to better understand the technical solutions in the embodiments of this application, and to make the above-mentioned objectives, features, and advantages of the embodiments of the present application more obvious and understandable, the following describes the technology in the embodiments of the present application with reference to the accompanying drawings. The plan is explained in detail.

Before describing the technical solutions of the embodiments of the present application, first, the technical scenarios of the present application will be introduced with reference to the accompanying drawings.

The technical solution of this embodiment is applied to the field of data storage. Further, in the field of data storage, it can be applied to a continuous data protection (CDP) system or a copy data management (copy data management, CDM) system. For example, referring to FIG. 1, there is shown a schematic structural diagram of a CDP system. The CDP system includes a server cluster 10, a production center 20, a disaster recovery center 30 and a CDP management module 40.

The server cluster 10 includes at least one server, such as but not limited to a Web server 11, a file server 12, and a database server 13, and each server has at least one local disk or array, and each local disk/array is used for storage. The data of the server.

The production center 20 includes at least one storage array that is used to store data sent by the server cluster 10. For example, the production center 20 includes

storage arrays

1, 2 and 3, where the storage array 1 is used to store data from the Web server 11. The storage array 2 is used to store data from the file server 12, and the storage array 3 is used to store data from the database server 13.

Further, each storage array may be a storage device known in the current technology, such as redundant arrays of independent disks (Redundant Arrays of Inexpensive Disks, RAID), disk clusters (Just a Bunch Of Disks, JBOD), and direct access storage ( Direct Access Storage Device (DASD) is one or more interconnected disk drives, such as a tape library, and one or more storage unit tape storage devices.

Specifically, as shown in FIG. 2, each storage array may include a controller 21 and a memory 22. Among them, the controller 21 includes a processor 211 and a cache 212. The processor 211 is used to execute input and output IO commands and other data services; the cache 212 is a memory existing between the controller 21 and the hard disk. Although the storage capacity is smaller than that of the hard disk, the operating speed is much faster than that of the hard disk. The memory 22 is mainly a storage medium, and the storage medium is used to provide storage space. Generally, it refers to a non-volatile memory (NVM), such as a read-only memory, ROM), Programmable Read-only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Flash Memory (flash memory), etc.

The structure of the disaster recovery center 30 is similar to that of the production center 20. The disaster recovery center 30 includes at least one storage array. The storage array may also be called a disaster recovery array. Specifically, the structure of the disaster recovery array is the same as that of the production center. The storage array structure of the center 20 is the same, and will not be repeated here.

Wherein, in the production center 20 and the disaster recovery center 30, the storage space of each storage array or disaster recovery array may include at least one data volume, and each data volume is a segment of logical storage space mapped from physical storage space, for example The data volume can be a logical unit number (Logic Unit Number, LUN) or a file system.

It should be noted that the storage array may also be referred to as a storage unit (the cylinder of the production center 20 shown in FIG. 1), and further, the storage unit may be a physical hard disk (such as a magnetic disk, a memory stick, a solid state). A hard disk or other non-volatile storage medium), or a partition in a hard disk, can also be a segment of logical space virtualized by the physical space provided by the hard disk, such as a logical volume or LUN.

In the embodiment of the present application, the upper layer of the storage array (or disaster recovery array) may also include a file system, through which file system management and management in the form of files between the storage arrays of the production center 20 and the disaster recovery center 30 are realized. Access data.

In addition, the CDP system shown in FIG. 1 also includes a CDP management module 40. The CDP management module 40 can be used to capture all file access operations sent by the server cluster in real time, and combine the file data changes with the current system time stamp. ) Together with automatic backup to the disaster recovery center.

For example, the production center 20 and the CDP management module 40 can be deployed in two different locations in the same city, and the distance between them can be within 100 km. Data transmission may be performed between the production center 20 and the CDP management module 40 through an IP protocol (Internet Protocol) or a fiber channel (fiber channel, FC). The production center 20 and the disaster recovery center 30 can use synchronous remote replication to achieve data disaster recovery. For example, when the production center 20 receives a data write request sent by the Web server 11, it can write the data carried in the data write request into the storage array 1 of the production center, and then send the data carried in the data write request. The backup center 30 stores the data in the disaster backup array 1 after receiving the data. After the data is successfully written into the disaster recovery array 1, the production center 20 returns the write completion response of the data write request (also called the response message of the data write request) to the Web server 11.

Optionally, the CDP management module 40 may be implemented by software, hardware, or a combination of software and hardware. For software, the CDP management module can be installed on any server in the server cluster 10, or in the production center 20. For the hardware implementation level, the CDP management module 40 may be an independent device, such as a site or a server. The embodiment of the present application does not limit the integrated location and specific form of the CDP management module 40.

During the disaster recovery backup process, the CDP management module 40 takes a snapshot of the disaster recovery array in the disaster recovery center 30 every time a time interval has elapsed to generate snapshot data. For example, in Figure 1, the CDP management module 40 updates the data in the disaster recovery array every 30 minutes (min). For example, at 10:00, 10:30, and 11:00, the data for the storage array 1 of the production center 20 is generated. Three snapshot data. At the same time, it also includes generating snapshot data in other storage arrays, for example, generating three snapshot data of the storage array 2 and the storage array 3 of the production center 20.

The snapshot can be understood as an image of the data at a certain point in time. The purpose of generating a snapshot is to create a state view for the data volume at a specific point in time. Through this view, you can only see the data of the data volume at the time of creation. After this point in time, the data volume is modified (new data is written) , Will not be reflected in the snapshot view. Using this snapshot view, you can copy the data at a certain creation time. When a certain creation time is regarded as the recovery time, it can also be called Recovery Time. The data backed up at the recovery time is used as a recovery point objective (RPO) or recovery time objective (RTO).

Among them, this embodiment does not limit the time interval of disaster recovery backup (or creation time), which can be minutes, such as 30min, 10min; it can also be seconds, such as 30 seconds (s), 20s, 10s Etc., the smaller the time interval, the more snapshot data will be generated, which can facilitate the recovery from any disaster scenario when the user performs data recovery, thereby minimizing the loss of data.

Refer to FIG. 3, which is a schematic structural diagram of another CDP system provided by an embodiment of this application. The system includes a production center, a disaster recovery center, a CDP management module, a control plane and a user interface (UI). Wherein, the CDP management module is located in the production center, and is used to intercept each IO request and send the intercepted IO request to the disaster recovery center for disaster recovery backup. In addition, file data such as application programs, file systems, volumes, and hard disks are stored in a storage array in the production center. Snapshot data generated at different times are stored in the disaster recovery center. Each snapshot data can be stored on a snapshot disk. For example, Figure 3 shows a total of n snapshots taken from time t1 to time tn, and n snapshots are generated. The snapshot data is stored on the n snapshot disk.

In addition, the system also includes a data analysis module, which is used to obtain the snapshot data generated at each creation time, and detect the snapshot data at each time to generate a detection result. Further, the data analysis module can be implemented in the form of software, hardware, or software and hardware, and this embodiment does not limit the specific form of the data analysis module.

The method provided by the embodiment of the present application will be described in detail below.

As shown in FIG. 4, this embodiment provides a data detection method, which is applied to CDP backup of data in a local disk array. The method may be implemented by the data analysis module shown in FIG. 3. Specifically, the method includes:

Step 101: When generating the first snapshot data at the first moment, obtain the data in the first disaster recovery array.

Wherein, the data in the first disaster recovery array includes the first snapshot data. The first disaster recovery array is any storage array or storage unit in the disaster recovery center, and the disaster recovery center includes at least one disaster recovery array. Further, in the server cluster, the CDP management module writes the data in the first local disk array of the first server to the first storage array of the production center, and at the same time backs up the data in the first disaster recovery array of the disaster recovery center. And generate snapshot data at different timestamps, for example, generate the first snapshot data at the first moment. Among them, the snapshot data generated at each moment can be a recovery point RPO.

Step 102: Detect data in the first disaster recovery array to obtain a first detection result.

Specifically, the detection of the data in the first disaster recovery array includes first-level detection and second-level detection.

(1) The first layer detection specifically includes: detecting the block device where the data in the first disaster recovery array is located.

Wherein, the block device may be a kind of disk, such as C disk, D disk and so on. The block device includes volumes and partitions. A specific implementation is that in the first-level detection process, if a block device, such as a disk, is deleted, or a volume or partition in the disk is added or deleted, then It is determined that the block device of the first disaster recovery array has changed; otherwise, it is determined that there is no change.

Further, the process of judging whether the disk, or the volume or partition in the disk is added or deleted, specifically includes: analyzing the disk information in the LUN, and comparing the current disk information with the disk information of the last recovery point, to obtain the disk changes, Enter the analysis data. In this embodiment, the volume information of the first disaster recovery array at the first moment is compared with the volume information of the last recovery point to obtain the volume change and record it in the analysis data.

It should be understood that the LUN described in this embodiment is an abbreviation for LUN Device (LUN Device).

The second layer of detection is performed when the first layer of detection has not changed.

(2) The second layer detection specifically includes: detecting files in the block device.

Wherein, the files in the block device are stored in the volume, so the second layer detection is also to detect the change of the file data on the volume. Specifically, the data analysis module identifies the file system data on the volume, analyzes the integrity and consistency of the file system data, and records the analysis data. In one example, at least one file can be obtained by analyzing the file system data. Read the interface. The files in the file system include at least one of the following:

a. File system log files;

b. Operating system configuration files;

c. Operating system log files.

Wherein, the file system log file records the daily activities of the file system, including errors, alarms, and so on. The operating system configuration file is a core configuration file of the operating system, such as a Windows registry file, etc., which can affect whether the operating system starts and runs normally. The operating system log file log saves operating system activities within a period of time, such as a series of activities such as adding, deleting, and modifying a certain file/directory.

For the detection of "a" files, one implementation method includes: reading each file system log file through the file reading interface; further, analyzing the change of each log file through the log file, such as the increase of log files, Delete, modify, etc., and record the analysis data.

For the detection of the "b" file, an implementation method includes: reading the operating system configuration file through the file system interface; further, analyzing the operating system configuration file and comparing it with the key configuration file of the previous recovery point, Obtain the changes of the configuration file and record it in the analysis data.

For the detection of the "c" file, one implementation method includes: reading the operating system log file through the file system interface; further, analyzing the operating system log file to obtain the error and alarm logs therein, and resolving key errors and alarms. The log is recorded in the analysis data.

Step 103: Generate a detection report of the first snapshot data according to the first detection result.

The detection report of the first snapshot data includes the detection results of all files in the block device and the file system. For example, if a certain partition in the block device is deleted, the detection report records the name and number of the partitions backed up in the first disaster recovery array at the first moment. For another example, when detecting the file system log file, it is detected that at least one new error and alarm log is added, and then these newly added error and alarm logs are recorded.

In addition, the method further includes: the data analysis module stores the detection report of the first snapshot data at the first moment, and the control plane accesses the detection report and displays the detection report on the user interface.

In a possible implementation manner, the method further includes:

When the data analysis module generates the first snapshot data at the second time, the first snapshot data at the second time is stored in the first disaster recovery array, and the data of the first disaster recovery array stored at the second time is acquired; Detect the data in the first disaster recovery array at the second time to obtain a second detection result; generate the second detection result according to the second detection result and the detection report of the first snapshot data at the first time The detection report of the first snapshot data at the moment.

Specifically, in the process of generating the detection report at the second time, the detection result at the first time is compared with the detection result at the second time to obtain the change of the file data in the first disaster recovery array, for example, at the second time The number of operating system configuration files in the first disaster recovery array is more than three times the file data at the first time, and the change is recorded in the detection report at the second time.

It should be understood that after the data analysis module generates snapshot data at each moment, it immediately detects the snapshot data and generates a detection report, so as to achieve the effect of real-time detection of file data at each recovery point.

The method provided in this application performs a file-level health check on the data in the disaster recovery array, which is detailed to each specific file. Therefore, when the system has a virus intrusion, it can reflect the changes of the disaster recovery array at two moments before and after. When the user checks the recovery point or wants to recover the data at a certain time, the target recovery point can be determined only by the file change shown in the detection report generated in real time, so as to quickly restore the data at the target recovery point. It achieves the effect of what users see is what you get, and avoids users from blindly and experimentally finding the target recovery point, which will consume a lot of time.

It should be noted that, in this embodiment, the data stored in the disaster recovery array can be divided into weak background data and strong background data. The weak background data refers to data formats that the CDP system can analyze and process on its own, such as partitions, disks, volumes, file system data, and so on. Generally, static data analysis is used to find useful data and files through the analysis of the data format, and analyze the health of these data and files.

The strong background data refers to a data format that the CDP system cannot analyze and process by itself, and needs to rely on a third-party program for analysis, such as some application data. The application data includes data that a user specifies a certain application object, such as a certain database. Since the file format of application data is generally non-public, it is necessary to rely on a third-party program of the application itself to analyze the data.

Further, for the detection of strong background data stored in the disaster recovery array, one implementation manner is that the first snapshot data of the first disaster recovery array at the first moment includes at least one application data generated by an application. In this case, the first snapshot data is run, and a third-party program is used to detect the addition, deletion, and modification of the application data generated by the at least one application. The specific detection process is the same as the foregoing detection process of the file system log file, operating system configuration file, and operating system log file. Refer to the above "a", "b" and "c" for the detection of each file, this embodiment I won't repeat them here.

In a specific embodiment, as shown in FIG. 5, it is a schematic diagram of a process for detecting weak data. And the detection process can be executed by a data analysis module. Specifically, the method includes:

Step 501: Open the disaster recovery array generated at the current moment, and start the block device, such as LUN, stored in the disaster recovery array.

LUN is the logical unit number, and its main function is to assign logical unit numbers (LUNs) to connected servers. After the hard disks on the Redundant Arrays (Redundant Arrays of Independent Disks, RAID) form a RAID group, usually the servers connected to the disk arrays cannot directly access the RAID group, but must be divided into logical units before they can be allocated to the servers. This is because the number of devices that can be attached to the Small Computer System Interface (SCSI) bus is limited, generally 8 or 16, generally you can use the controller (Target) ID (also called SCSI ID) ) To describe these devices. When a device is added to the system, it will be assigned a code, which is used to distinguish each device. For example, a logical unit number is introduced to identify the LUN ID, where the LUN ID can be used to expand the Target ID. There may be multiple LUN devices (Devices) under each target. In this embodiment, the LUN Device is referred to as LUN for short.

Step 502: Analyze the block device data in the disaster recovery array, specifically, compare the block device data at the current moment with the block device data at the previous moment to obtain disk changes and record them in the analysis data. In addition, if it is detected that the block device data has not changed, step 403 is executed.

Step 503: Analyze the volume information on the disk, compare the volume information with the volume information stored in the disaster recovery array at the previous moment, obtain volume changes, and record the analysis data. When it is detected that the volume information has not changed, step 404 is executed.

Step 504: Identify the file system on the volume;

Step 505: Analyze the data in the file system and record the analysis data. Further, step 405 specifically includes:

Step 5051: Read the operating system configuration file through the file system configuration interface.

Step 5052: Obtain the error and alarm logs in the configuration file, and record them in the analysis data.

Step 5053: Read the operating system log file through the operating system interface.

Step 5054: Obtain the error and alarm logs in the log file, and record the analysis data.

Step 5055: Read the file system log file through the file system interface.

Step 5056: Analyze and obtain the change situation of the log file, and the change situation includes: addition, deletion, modification, etc. of the log file, and record the analysis data.

It should be noted that in this embodiment, the execution order of the

above steps

5051, 5053, and 5055 is not limited, and these three steps can be executed in order or at the same time. In addition, in this embodiment, step 5052 is performed at the same time. The execution order of step 5054 and step 5056 is also not limited.

Step 506: Summarize the data of the above step 503, step 5052, step 5054, and step 5056, analyze the data to obtain the detection result, and generate a detection report.

Step 507: Shut down the LUN and complete the detection.

It should be noted that step 506 in this embodiment may be executed by a data analysis module, or may also be executed by other modules or units, which is not limited in this embodiment.

In another specific implementation, for strong background data, when the data analysis module does not have the ability to analyze and process some application data, such as user-specified data and database, it needs to be analyzed through a third application. And detection. The strong background data may be obtained when the data analysis module obtains the backup data of the disaster recovery array, or the remaining files after detecting the weak background data include the strong background data. This embodiment compares the strong background data The method of obtaining is not limited.

Specifically, in an example, as shown in FIG. 6, the method includes:

Step 601: The data analysis module mounts the LUN to the virtual machine, and powers on the virtual machine;

The storage array (such as a snapshot disk) produced in the production center of the CDP system can support exporting to a virtual disk in vmdk format, and the exported vmdk virtual disk can be directly mounted to the virtual machine for use, realizing the snapshot system and virtualization The seamless combination between the snapshot disks can be converted to a virtualized disk format and directly used in the virtualized system.

Step 602: Start the virtual machine system.

Step 603: Use a third-party application to obtain an application log access interface.

Step 604: Use the application log access interface to detect the application log.

Further, the change of each application log file is analyzed through the application log access interface, such as the addition, deletion, modification, etc. of the application log file, and the analysis data is recorded. Among them, the application data contained in the application log file can be the data of a certain application object (such as a certain database) specified by the user,

Step 605: The data analysis module obtains the detection results of each application log file, and combines the previous detection results of the weak background data to summarize and analyze the recorded data, and generate a detection report.

Step 606: Shut down the virtual machine system.

Step 607: Uninstall the LUN, and the detection is complete.

In this method, when detecting strong background data, the virtual machine system is pulled up on the snapshot disk at a certain moment, and the third-party application program runs and analyzes the log file of the application under the virtual machine system, and records the detection As a result, the detection of strong background data is realized, and the modification record of the log file containing the specific application is generated, thereby helping the user to determine the best recovery point before the object modification.

The method of this embodiment analyzes the backup data in the disaster recovery array in real time, including analysis of weak background data and strong background data addition, deletion, modification, errors and alarms, so as to obtain the disaster recovery array of each time stamp. The health of the backup data is what you see is what you get for the user's recovery point data, paving the way for the user to quickly find the target recovery point.

It should be understood that when detecting the backup data of the disaster recovery array, the detection items of the backup data can be expanded, for example, combined with the anti-virus database, or by analyzing the virus signature files provided by the virus database to accurately determine the information in each snapshot disk Whether the data in is infected by a virus, the embodiment of this application does not limit the specific detection process of the backup data.

Referring to FIG. 7, a data detection device provided in this embodiment is applied to a scenario where CDP disaster recovery backup of data in a local disk array is performed, and the method in the foregoing embodiment is executed. Specifically, the device includes: an acquisition unit 710 and a processing unit 720. In addition, the device may further include more units, such as a sending unit, a storage unit, etc., which are not limited in this embodiment.

Specifically, the acquiring unit 710 is configured to acquire data in the first disaster recovery array when generating the first snapshot data at the first moment, where the data in the first disaster recovery array includes the first snapshot data; the processing unit 720 is configured to detect data in the first disaster recovery array to obtain a first detection result, and generate a detection report of the first snapshot data according to the first detection result.

Optionally, in a specific implementation of this embodiment, the processing unit 720 is specifically configured to perform a first layer detection on the data in the first disaster recovery array, and the first layer detection includes detecting the Whether the block device where the data of the first disaster recovery array is located has changed; if there is no change, a second layer detection is performed, and the second layer detection includes detection of files in the block device.

Wherein, the file includes: at least one of a file system log file, an operating system configuration file, and an operating system log file.

Further, the processing unit 720 is specifically configured to read each of the file system log files and analyze the addition, deletion, and modification of each log file when the file system log file is detected; During system configuration file detection, read each of the operating system configuration files, analyze each configuration file, compare it with the key configuration file at the previous moment, and obtain the changes in each configuration file; When the log file is detected, each of the operating system log files is read, each log file is analyzed, and the log recorded as an error or warning in the log file is obtained, and the log of the error or warning is recorded.

Optionally, in another specific implementation manner of this embodiment, the first snapshot data further includes application data generated by at least one application, and the processing unit 720 is further configured to use a third-party program to perform data processing on the at least one application. The addition, deletion, and modification of the application data of an application are detected, and the detection result is obtained.

Optionally, in another specific implementation manner of this embodiment, the obtaining unit 710 is further configured to obtain the storage in the first disaster recovery array at the second time when the first snapshot data at the second time is generated. The processing unit 720 is further configured to detect the second snapshot data to obtain a second detection result; and, according to the second detection result and the detection report of the first snapshot data at the first moment To generate a detection report of the second snapshot data at the second moment.

It should be noted that the devices described in the embodiments can be implemented by software, such as a data analysis module, or can also be implemented by hardware or a combination of software and hardware, such as running the software on a computer or a processor. Specifically, the acquiring unit 710 and the processing unit 720 may be integrated in a computer or a processor, or a software module required for processing operation, or a combination of the two.

A possible implementation manner is that the data analysis module is located in a disaster recovery array. For example, the data analysis module is added to the disaster recovery array of FIG. 2. The structure is shown in FIG. 8, and includes a controller 21 and a memory. 22. The controller 21 includes a processor 211 and a cache 212, and further, the processor 211 includes a data analysis module 2110.

The controller 21 is the control center of the disaster recovery array. It uses various interfaces and lines to connect the various parts of the entire disaster recovery array, runs or executes the software programs and/or units stored in the memory 22, and calls the memory 730. Data to perform various functions of the disaster recovery array.

Further, the processor 211 may be composed of an integrated circuit (Integrated Circuit, IC), for example, may be composed of a single packaged IC, or may be composed of connecting multiple packaged ICs with the same function or different functions. For example, the processor 211 may only include a central processing unit (CPU), or may be a combination of a GPU, a digital signal processor (DSP), and a control chip. The processor 211 may further include a hardware chip. The hardware chip may be an application specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

The memory 22 may include a non-volatile storage medium, such as a flash memory, a hard disk (Hard Sisk Drive, HDD), or a solid-state hard disk (Solid-State Drive, SSD). A program or code may be stored in the memory, and the processor 211 may implement the functions of the above-mentioned data detection device by executing the program or code.

In the above-mentioned embodiments, all or part of it may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, it may be implemented in the form of a computer program product in whole or in part, which is not limited in this embodiment. For example, the functions of the acquisition unit 710 and the processing unit 720 in the aforementioned device embodiment shown in FIG. 7 may be implemented by the controller 21, and the functions of the storage unit may be implemented by the memory 22.

In a possible implementation manner, the data detection device may be configured in a separate device, for example, the separate device is a communication device, and the structure of the communication device may be the same as the disaster recovery array shown in FIG. 7, including Controller and memory. The controller is coupled with a memory, and program instructions are stored in the memory; when the controller is used to execute the program instructions in the memory, it can cause the communication device to execute the methods in FIGS. 4 to 6 of the foregoing embodiment.

Optionally, the communication device is a network device, such as a server.

The embodiments of the present application also provide a computer program product, and the computer program product includes one or more computer program instructions. When the computer loads and executes the computer program instructions, all or part of the processes or functions described in the foregoing embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

The steps of the method described in this application can be directly embedded in hardware, a software unit executed by a processor, or a combination of the two. The software unit can be stored in flash memory, ROM, EPROM, EEPROM, register, hard disk, removable disk, or any other storage medium in the field. Exemplarily, the storage medium may be connected to the processor, so that the processor can read information from the storage medium, and can store and write information to the storage medium. Optionally, the storage medium can also be integrated into the processor.

In addition, the terms "first" and "second" in the description and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific sequence or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments described herein can be implemented in a sequence other than the content illustrated or described herein. In addition, the terms "including" and "having" and any variations of them are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those clearly listed. Those steps or units may include other steps or units that are not clearly listed or are inherent to these processes, methods, products, or equipment.

The same or similar parts in the various embodiments in this specification can be referred to each other. In particular, as for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the description in the method embodiment.

The implementation manners of the application described above do not constitute a limitation on the protection scope of the application.

Claims

A data detection method, characterized in that the method includes:

When generating the first snapshot data at the first moment, acquiring data in a first disaster recovery array, where the data in the first disaster recovery array includes the first snapshot data;

Detecting data in the first disaster recovery array to obtain a first detection result;

A detection report of the first snapshot data is generated according to the first detection result.
The method according to claim 1, wherein detecting data in the first disaster recovery array comprises:

Performing a first layer detection on the data in the first disaster recovery array, the first layer detection including detecting whether the block device where the data of the first disaster recovery array is located has changed;

If there is no change, a second-level detection is performed, and the second-level detection includes detection of the file in the block device.
The method according to claim 2, wherein the file comprises at least one of a file system log file, an operating system configuration file, and an operating system log file.
The method according to claim 3, wherein the first snapshot data further includes application data generated by at least one application;

The method further includes: using a third-party program to detect the addition, deletion, and modification of the application data generated by the at least one application.
A data detection device, characterized in that the device includes:

An obtaining unit, configured to obtain data in a first disaster recovery array when generating the first snapshot data at the first moment, where the data in the first disaster recovery array includes the first snapshot data;

The processing unit is configured to detect the data in the first disaster recovery array to obtain a first detection result, and generate a detection report of the first snapshot data according to the first detection result.
The device of claim 5, wherein:

The processing unit is specifically configured to perform a first layer detection on data in the first disaster recovery array, and the first layer detection includes detecting whether a block device where the data of the first disaster recovery array is located has changed; If there is no change, a second-level detection is performed, and the second-level detection includes detection of the file in the block device.
The device according to claim 6, wherein the file comprises at least one of a file system log file, an operating system configuration file, and an operating system log file.
8. The device according to claim 7, wherein the first snapshot data further includes application data generated by at least one application;

The processing unit is further configured to use a third-party program to detect the addition, deletion, and modification of the application data generated by the at least one application.
A communication device includes a controller, the controller is coupled with a memory, and is characterized in that:

The memory is used to store computer program instructions;

The controller is configured to execute the instructions stored in the memory, so that the communication device executes the method according to any one of claims 1 to 4.
A computer-readable storage medium, characterized in that computer program instructions are stored in the computer-readable storage medium,

When the computer program instructions are executed, the method according to any one of claims 1 to 4 is implemented.