Generating file chunk change information for backups

Abstract

The invention relates to generating file block change information for a backup. Example implementations relate to computer data storage. In some examples, a file system scanner identifies files in a file system, where each file includes a logical block, and where the file system is included in a backup. A file system scanner generates a read buffer to store logical blocks of a file. The block filter driver determines that the read buffer includes a predefined signature, and in response determines whether the logical block has been modified in the backup. In response to determining that the logical block has been modified in the backup, the block filter driver sets a modification flag in the read buffer to a value indicating that the logical block has been modified.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0001] Some embodiments are described with respect to the following drawings.

[0002] Figure 1 is a schematic diagram of an example system in accordance with some embodiments.

[0003] Figures 2A-2B is a diagram of an example data structure in accordance with some embodiments.

[0004] Figure 3 is a diagram of an example process in accordance with some embodiments.

[0005] Figure 4 is a schematic diagram of an example computing device in accordance with some embodiments.

[0006] Figure 5 is a diagram of an example process in accordance with some embodiments.

[0007] Figure 6 is a diagram of an example machine-readable medium storing instructions in accordance with some embodiments.

[0008] In all of the drawings, like reference numerals refer to like parts throughout the several views. The drawings are not necessarily to scale, and the dimensions of some parts can have been exaggerated for the sake of clarity and convenience in illustrating the examples and / or embodiments presented herein; however, the drawings are intended as exemplary and / or illustrative only and the description is not limited to the examples and / or embodiments presented in the drawings. DETAILED DESCRIPTION

[0009] In this disclosure, the use of the term “a,” “an,” or “the” is intended to mean one or more, unless the context clearly indicates otherwise. Likewise, the use of the term “includes,” “including,” “comprises,” or “comprising” is intended to mean that there are other items or elements in addition to those listed, but does not mean that there are no other items or elements. Also, the use of the term “if’ is intended to mean “when” or “whether” in some examples, dependent on the context in which it is used.

[0010] In some examples, a storage system can store data units in persistent storage. Persistent storage can be implemented using one or more persistent (e.g., non-volatile) storage devices such as disk-based storage devices (e.g., hard disk drives (HDDs)), solid state devices (SSDs) such as flash storage devices, or the like, or a combination thereof. As used herein, a "controller" can refer to a hardware processing circuitry, which can include any one or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or other hardware processing circuitry. Alternatively, a "controller" can refer to a combination of hardware processing circuitry and machine-readable instructions (software and / or firmware) that are executable on the hardware processing circuitry.

[0011] In some examples, a data collection can be specified in terms of one or more elements of a file system. As used herein, a "file system" is a system for organizing data stored in a storage device. For example, a file system can include a collection of data files stored in a directory hierarchy (e.g., including a root directory and one or more levels of subdirectories). To present data as a collection of data files and directories, a file system can maintain a structure of metadata. In the context of a file system, the term "metadata" refers to information that describes volumes, files, and directories, but is not part of the stored data files. For example, the following items of information describe a data file and are considered part of the file's metadata: file name, file size, creation time, last access / write time, user id, and block pointers to the file's actual data on the storage device. The items of information that make up the metadata of a directory include primarily the names and references of the data files and subdirectories included in the directory.

[0012] In some examples, a data collection can be stored on a block-based storage device. As used herein, a "block-based" storage device can refer to a device that stores data at a block level. In examples described herein, the term "block level" refers to a level of data storage that is lower than the level at which files and directories are stored. In such examples, the block level can be the level at which a block-based storage device can store data, or it can be the level at which a file system implements files and directories. A block-based storage device can receive data blocks that make up a data collection as a stream of data blocks.

[0013] In some examples, a backup process of a computing system can include copying data blocks stored in a storage device (e.g., a storage array) to a backup device that can store the data blocks in a form that is a backup. In examples described herein, a “backup” can refer to a form that a backup device stores a collection of data in, which can be different from a form in which the data blocks are stored on a storage device (e.g., a storage array) from which the data blocks are backed up. For example, a backup can include a deduplicated representation of data blocks that are copied to a backup device for backup. In some examples, a backup process can copy a specified collection of data in files and directories of a file system stored on a storage device to a backup device.

[0014] In some examples, the specified collection of data to be copied to a backup device can include one or more volumes of a storage device, a portion or all of a file system stored on a storage device (e.g., all data stored under a given directory, such as a root directory or one or more subdirectories), etc. When generating a full backup, a backup process can copy all data blocks of the specified collection of data to a backup device, which can store them as a backup, referred to herein as a “full backup.” When generating an incremental backup, a backup process can specifically copy data blocks of the specified collection of data that have changed since a previous backup, and a backup device can store these changed blocks in a form referred to herein as an “incremental backup.” As used herein, a “snapshot” can be a representation of data included in a storage volume (or other collection of data) at a particular point in time. For example, a full backup can represent a snapshot of an initial point in time, while a combination of a full backup and an incremental backup can represent a different snapshot of a later point in time.

[0015] In some examples, it can be useful to identify which files and file blocks (i.e., data blocks in files) were modified in a particular backup. For example, such information can be used to detect whether ransomware that has maliciously encrypted portions of a file system is present. Further, in some examples, identifying modifications in a file system can involve retrieving backup data from storage, mounting a file system, identifying files in the file system, reading file metadata (e.g., a timestamp of “last modified”), and comparing this information to earlier versions of file metadata. However, such techniques can be susceptible to timestamp manipulation by malware and can not provide detailed information about block-level modifications within files.

[0016] According to some embodiments of the present disclosure, a computing device can execute a file system scanner and a block filter driver to determine which files and data blocks were modified in a particular backup. The file system scanner can identify each file in the file system and can issue read calls to retrieve data blocks in the identified files. Further, the file system scanner can write a special signature into the read buffer for the read calls. The block filter driver can intercept each read call and, in response, can determine whether the special signature is present in the read buffer associated with the read call. If the special signature is present in the read buffer, the block filter driver can prevent the normal execution (e.g., by the operating system) of the read call to retrieve the requested data block and, instead, perform an alternative function or operation (referred to herein as "block change detection") to determine whether the requested data block was modified in the most recent backup. In some embodiments, the block change detection operation can involve performing a lookup for the requested data block in the changed block data structure. Subsequently, the block filter driver can populate the read buffer with block change information indicating which data blocks, if any, were modified in the backup. The file system scanner can obtain the block change information from the read buffer and can use the information to generate a modification report. In this way, some embodiments can provide block change information that identifies modifications to the file system that occurred at the data block level and that was generated in a way that is not subject to timestamp manipulation by malware. Reference is made to the following detailed description of specific embodiments of the present disclosure, illustrative examples of which are shown in the accompanying drawings. Figures 1-6 Various aspects of the disclosed technology are further discussed.

[0017] Figure 1 - example system

[0018] Figure 1 An example system 100 according to some embodiments is shown. The system 100 can include a computing device 110 and a block-level storage 160. The computing device 110 can be a physical computing device (e.g., a server, a device, a desktop, etc.), a virtual computing device (e.g., a virtual machine, a container, etc.), and the like. Further, the block-level storage 160 can be all or a portion of a local storage device, a storage appliance, a storage array, a remote storage service, and the like. In some embodiments, the computing device 110 and the block-level storage 160 can be implemented in different devices and / or locations. However, in other embodiments, the computing device 110 and the block-level storage 160 can be implemented in a single device and / or system (e.g., a server, a server rack, etc.).

[0019] In some embodiments, the block-level storage 160 can be implemented using a non-transitory storage medium (e.g., a hard disk drive, a solid state drive), a semiconductor memory (e.g., random access memory), and the like. As Figure 1As shown, block-level storage device 160 can store backups 170 (or multiple backups 170) in the form of data blocks. Each backup 170 can represent the state of a given file system (or a volume including a file system) at different points in time (e.g., at the time of the most recent backup operation of the volume). Further, in some embodiments, block-level storage device 160 can store data blocks in a deduplicated form.

[0020] In some embodiments, computing device 110 may include controller 112 and memory 114. Controller 112 may be implemented via hardware (e.g., electronic circuitry) or a combination of hardware and programming (e.g., including at least one processor and instructions executable by said at least one processor and stored on at least one machine-readable storage medium). Memory 114 may be implemented using semiconductor memory such as random access memory (RAM). In some embodiments, memory 114 may include user space 115 and kernel space 116. User space 115 may be part of the storage of memory 114 containing user processes being executed by controller 112. Further, kernel space 116 may be part of the storage of memory 114 containing an operating system kernel being executed by controller 112.

[0021] In some implementations, computing device 110 may host or execute file system scanner 120, block filter driver 140, and operating system ( Figure 1 (Not shown in the diagram) and any number of other components. The file system scanner 120 and the block filter driver 140 may be implemented by a controller 112 that executes instructions (e.g., software and / or firmware) stored in a machine-readable storage medium or in hardware (e.g., circuitry). In some embodiments, the file system scanner 120 may execute in user space 115, while the block filter driver 140 may execute in kernel space 116.

[0022] In some implementations, a combination of file system scanner 120 and block filter drive 140 can be used to identify files and data blocks that have been modified in a given backup 170. In some examples, file system scanner 120 can access backup 170 stored in block-level storage device 180 and can mount file system 130 from the accessed backup 170 (e.g., using the Linux “mount” command). In other examples, file system scanner 120 can access the backup 170 from the source volume used to generate it (…). Figure 1The file system 130 (e.g., at the time of generating the backup 170) is mounted (not shown). The file system scanner 120 can traverse the file system 130 to identify each file in the file system 130. Further, the file system scanner 120 can use the file system 130 to identify logical blocks included in each file. Each logical block can represent a corresponding physical block stored in the backup 170. As used herein, the term "physical block" can refer to a block of data having an address that represents the actual physical location of the block of data in a storage device or memory and is used by system hardware. Further, the term "logical block" can refer to a block of data having an address that is a virtual or symbolic representation of its storage location and is used by software programs.

[0023] In some implementations, the file system scanner 120 can generate or otherwise prepare one or more read buffers 180 in the user space 115. Each read buffer 180 can be configured to receive a different logical block included in the identified files. Further, the file system scanner 120 can send one or more read calls 125 to the operating system kernel to request the logical blocks included in the identified files. In some implementations, the file system 130 can receive the read calls 125 from the file system scanner 120 and can map or translate each logical block (requested in the read calls 125) to its corresponding physical block.

[0024] In some implementations, the read calls 125 can be performed using a direct input / output (I / O) mode or setting. The direct I / O mode can cause the read calls 125 to fetch data directly from the storage device, to a buffer in the user space (i.e., without using a buffer in the kernel space 116). For example, when using the direct I / O mode, the file data requested by the file system scanner 120 (e.g., via the read calls 125) is transferred directly from the block-level storage 180 to the read buffers 180 in the user space 115, thereby avoiding the use of read buffers in the kernel space 116.

[0025] In some embodiments, prior to sending the read call 125 for a given file, the file system scanner 120 can initiate a direct I / O mode for the read call 125 by opening the file using a command flag or modifier (e.g., by issuing a Linux "OPEN" system call with an "O_DIRECT" flag to establish a connection to the file). The file system scanner 120 can populate the read buffer 180 (corresponding to the read call 125) with a special signature that indicates a block change detection operation. For example, the special signature can be a predefined bit sequence, a text string, a numeric string, etc. In some embodiments, the presence of the special signature in the read buffer prevents normal execution (e.g., by the operating system) of the read call 125 to fetch the requested logical block, and instead causes the block filter driver 140 to perform a block change detection operation on the requested logical block. Further, the file system scanner 120 can also populate the read buffer 180 with a modification flag (e.g., a bit value) that is set to an initial or default value (e.g., a value indicating that the requested logical block has not been modified in the backup 170).

[0026] In some embodiments, the block filter driver 140 receives the read call 125 from the file system 130 (e.g., after the file system 130 translates or maps the requested logical block in the read call 125 to a corresponding physical block). In response to receiving the read call 125, the block filter driver 140 can determine whether the corresponding read buffer 180 includes the special signature that indicates a block change detection operation. If not, the block filter driver 140 can allow the read call 125 to execute to fetch the requested data block from the block-level storage 160. Otherwise, if the block filter driver 140 determines that the read buffer 180 includes the special signature, the block filter driver 140 can perform a lookup in the changed block data 150 for the requested physical block, and can thereby determine whether the physical block was modified in the backup 170. In some embodiments, the changed block data 150 can be a stored data structure (e.g., a bitmap) that was generated with the backup 170 (e.g., by a backup process).

[0027] If the changed block data 150 indicates that the requested physical block was modified in the backup 170, the block filter driver 140 can set the modification flag (in the read buffer 180) to indicate that the requested logical block was modified in the backup 170. Otherwise, if the block filter driver 140 determines that the changed block data 150 indicates that the requested physical block was not modified in the backup 170, the modification flag can be set (or left unchanged if already set) to indicate that the requested logical block was not modified in the backup 170.

[0028] In some embodiments, after issuing the read call 125 for a logical block, the file system scanner 120 can read the modification flag in the read buffer 180 to determine whether the requested logical block was modified during the backup 170. Further, after processing each file in the file system 130 (e.g., by issuing read calls 125 for all logical blocks), the file system scanner 120 can generate modification data 190 (e.g., a report, list, database, or other data structure) that identifies each file and / or logical block that was modified during the backup 170. In this way, the file system scanner 120 and block filter driver 140 can provide block change information that identifies modifications to the file system 130 that occurred at the data block level and that was generated in a way that is not subject to timestamp manipulation by malware. Further, the file system scanner 120 and block filter driver 140 can provide such block change information for any type of file system that maintains a mapping of data blocks to files between writes (e.g., file systems that do not use copy-on-write technology for memory management).

[0029] In some embodiments, a single read call 125 can request a set of multiple contiguous logical blocks within a file. In such embodiments, the file system scanner 120 can generate a set of multiple read buffers 180 (in the user space 115), where each read buffer 180 corresponds to a different logical block requested by the read call 125. Further, the file system scanner 120 can populate each read buffer 180 with a sequence number that represents the order of the corresponding logical block in the set of contiguous logical blocks.

[0030] Figures 2A-2B - example data structures

[0031] Figure 2A A diagram illustrating an example read buffer 200 is shown in accordance with some embodiments. Referring now to FIG. 2, Figures 1-2A In some embodiments, the read buffer 200 can be generated by the file system scanner 120 prior to (or concurrently with) sending the read call 125 for the particular data block. The read buffer 200 can be located in the user space 115 of the memory 114.

[0032] In some embodiments, the file system scanner 120 can populate the read buffer 200 with a special signature 210, a modification flag 220, and a sequence number 230. The special signature 210 can be a predefined identifier (e.g., a sequence of bits, a string of text, a string of numbers, etc.) that indicates that the read call (associated with the read buffer 200) will perform a block change detection operation for the requested data block.

[0033] In some embodiments, the modified flag 220 can be a Boolean value (e.g., a bit value) that indicates whether the requested data block was modified in the backup of the file system. In some embodiments, when generating and populating the read buffer 200, the file system scanner 120 can initially set the modified flag 220 to indicate that the data block was not modified in the backup. Subsequently, if the block filter driver 140 determines that the requested data block was modified in the backup, the block filter driver 140 modifies or sets the modified flag 220 to indicate that the data block was modified in the backup.

[0034] In some embodiments, the sequence number 230 can indicate an order of the corresponding data block in a set of contiguous data blocks requested by the file system scanner 120 (e.g., in a single read call 125). In such embodiments, the file system scanner 120 can generate a set of multiple read buffers 180 (in the user space 115), where each read buffer 180 corresponds to a different data block. For example, referring now to Figure 2B , a diagram illustrating an example buffer set 250 including multiple read buffers 200 (labeled 200-1 through 200-N in the Figure 2B user space 115) is shown. As shown, each read buffer 200 in the buffer set 250 can include a sequence number (“SeqNum”) that indicates an order of the corresponding data block. The file system scanner 120 can generate the buffer set 250 when issuing a single read call to request a set of contiguous multiple data blocks.

[0035] Figure 3 - example process for generating chunk change information

[0036] Figure 3 An example process 300 for generating block change information, in accordance with some embodiments, is shown. The process 300 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by a processor). The machine-readable instructions can be stored in a non-transitory computer-readable medium such as an optical, semiconductor, or magnetic storage medium. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, and / or the like. As Figure 3 shown, in some embodiments, various actions of the process 300 can be performed by a scanner (e.g., the file system scanner 120 shown) and a block filter (e.g., the block filter driver 140 shown). For the sake of illustration, details of the process 300 can be described below with reference to Figure 1 and Figure 1 and Figure 1 and Figure 2A and Figure 2B other embodiments are possible.

[0037] Block 310 can include mounting the file system (FS) included in the backup. Block 315 can include identifying each file in the file system and the logical blocks (LBs) that make up each file. For example, referring to Figure 1 , the file system scanner 120 mounts the backup 170 stored in the block-level storage 160 and identifies each file in the file system 130. Further, the file system scanner 120 accesses the file system 130 to identify the logical blocks included in each file.

[0038] Referring again to Figure 3 , at block 320, a loop (defined by blocks 325, 330, 335, 340, 380, 390) can be entered to process each file identified in the file system. Block 325 can include opening the file in direct mode. Block 330 can include preparing buffers in user space. Block 335 can include filling each buffer with a special signature and modification flag. Block 340 can include issuing a read call for a set of logical blocks. Block 345 can include mapping each logical block to its corresponding physical block through the mounted file system. For example, referring to Figures 1-2B , the file system scanner 120 selects a particular file of the file system 130 and opens the file using direct I / O mode (e.g., by invoking direct I / O mode by issuing an open system call for the file using a command flag). Further, the file system scanner 120 generates a buffer set 250 including a plurality of read buffers 200, where each read buffer 200 corresponds to a different logical block of the file. The file system scanner 120 fills each read buffer 200 with a special signature 210, a modification flag 220, and a sequence number 230. Further, the file system scanner 120 issues a read call 125 to request a set of contiguous logical blocks included in the file. The file system 130 receives the read call 125 from the file system scanner 120 and converts each requested logical block to its corresponding physical block.

[0039] Referring again to Figure 3At block 350, a loop (defined by blocks 355, 360, 365, 370, 375) can be entered to process each physical block that is mapped to the requested logical block. Block 355 can include accessing the read buffer corresponding to the current physical block. Decision block 360 can include determining whether the read buffer includes the predefined special signature that indicates a block change detection operation. If it is determined that the read buffer does not include the predefined signature (“No”), process 300 can continue at block 365, which includes obtaining or reading the physical block from the persistent storage device and populating the obtained physical block into the read buffer. After block 365, process 300 can return to block 350 (i.e., to process another physical block). For example, referring to Figure 1 Block filter driver 140 receives read call 125 from file system 130 and then determines whether the corresponding read buffer 180 includes the predefined special signature. If read buffer 180 does not include the predefined special signature, block filter driver 140 allows read call 125 to execute to fetch the physical block from block-level storage 160.

[0040] Again referring to Figure 3 If it is determined at decision block 360 that the read buffer includes the predefined special signature (“Yes”), process 300 can continue at decision block 370, which includes determining whether the physical block was modified in the backup. If it is determined at decision block 370 that the physical block was modified in the backup (“Yes”), process 300 can continue at block 375, which includes setting a modified flag in the read buffer to indicate that the physical block was modified in the backup. After block 375 or if it is determined at decision block 370 that the physical block was not modified in the backup (“No”), process 300 can return to block 350 (i.e., to process another physical block). For example, referring to Figure 1 Block filter driver 140 determines that read buffer 180 includes the predefined special signature and, in response, performs a lookup in modified block data 150 for the requested physical block. In some implementations, modified block data 150 is a bitmap generated as part of (or with) backup 170 and indicates whether each physical block was modified in backup 170 (e.g., using a bit value corresponding to each physical block). If block filter driver 140 determines that the current physical block was modified in backup 170 (based on modified block data 150), block filter driver 140 sets modified flag 220 (in read buffer 200) to indicate that the requested logical block was modified in backup 170. Otherwise, if block filter driver 140 determines that the requested physical block was not modified in backup 170, block filter driver 140 can set (or leave unchanged if already set) modified flag 220 to indicate that the requested logical block was not modified in backup 170.

[0041] Referring again Figure 3 After processing the set of physical blocks at block 350, process 300 can continue at block 380 by reading the modification flags in the set of read buffers (created at block 330) to determine which requested logical blocks were modified during the backup. Block 390 can include generating output data (e.g., part of a report or a list) that identifies each file and / or logical block that was modified during the backup. After block 390, process 300 can return to block 320 (i.e., process another file in the file system). Further, after processing all files in the file system at block 320, process 300 can complete. For example, referring to Figure 1 After issuing read calls 125 for a set of logical blocks, file system scanner 120 reads modification flags 220 in read buffers 200 (in buffer set 250) to determine whether the corresponding logical blocks were modified during backup 170. Further, after processing each file in file system 130 (e.g., by issuing read calls 125 for all logical blocks), file system scanner 120 generates modification data 190 that identifies each file and / or logical block that was modified during backup 170.

[0042] Figure 4 - example computing device

[0043] Figure 4 A schematic diagram illustrating an example computing device 400 is shown. In some examples, computing device 400 can generally correspond to some or all of computing device 110 (as shown in FIG. 1). As shown, computing device 400 can include a hardware processor 402 and a machine-readable storage 405 containing instructions 410-450. Machine-readable storage 405 can be a non-transitory medium. Instructions 410-450 can be executed by hardware processor 402 or by a processing engine included in hardware processor 402. Figure 1

[0044] Instructions 410 can be executed to identify, by a file system scanner, a plurality of files included in a file system, where each file in the file system includes one or more logical blocks, and where the file system is included in a backup. For example, referring to Figure 1 File system scanner 120 mounts backup 170 stored in block-level storage 160 and identifies each file in file system 130. Further, file system scanner 120 accesses file system 130 to identify the logical blocks included in each file.

[0045] Referring again Figure 4 ​Instruction 420 can be executed to generate a read buffer via a file system scanner to store logical blocks of files included in the file system. For example, see reference... Figures 1-2B The file system scanner 120 selects a specific file in the file system 130 and opens the file using direct I / O mode (e.g., by issuing an open system call for the file using command flags to invoke direct I / O mode). Further, the file system scanner 120 generates a buffer group 250 comprising multiple read buffers 200, where each read buffer 200 corresponds to a different logical block of the file. The file system scanner 120 fills each read buffer 200 with a special signature 210, a modification flag 220, and a sequence number 230.

[0046] Refer again Figure 4 Instruction 430 can be executed to determine, via the block filter driver, whether the read buffer contains a predefined signature indicating a block change detection operation. For example, refer to... Figure 1 The file system scanner 120 issues a read call 125 to request a set of contiguous logical blocks included in the file. The file system 130 receives the read call 125 from the file system scanner 120 and converts each requested logical block into its corresponding physical block. The block filter driver 140 receives the read call 125 from the file system 130 and determines whether the corresponding read buffer 180 contains a predefined special signature indicating a block change detection operation.

[0047] Refer again Figure 4 Instruction 440 can be executed to determine, in response to determining that the read buffer includes a predefined signature, whether a logical block has been modified in the backup via the block filter driver. Instruction 450 can be executed to set a modification flag in the read buffer to a value indicating that the logical block has been modified in the backup via the block filter driver, in response to determining that the logical block has been modified. For example, refer to... Figure 1 The block filter driver 140 determines that the read buffer 180 includes a predefined special signature and, in response, performs a lookup for the requested physical block in the modified block data 150. If the block filter driver 140 determines that the current physical block in the backup 170 has been modified (based on the modified block data 150), the block filter driver 140 sets the modification flag 220 (in the read buffer 200) to indicate that the requested logical block has been modified in the backup 170.

[0048] Figure 5 - example process

[0049] Figure 5 An example process 500 according to some implementations is shown. In some examples, process 500 may be generated by a computing device (e.g., Figure 1The process 500 can be performed by the computing device 110 shown in FIG. 1. The process 500 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by a processor). The machine-readable instructions can be stored in a non-transitory computer-readable medium such as an optical storage device, a semiconductor storage device, or a magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, and the like. However, other implementations are possible.

[0050] Block 510 can include identifying, by a file system scanner executed by the controller, a plurality of files included in a file system, wherein each file in the file system includes one or more logical blocks, and wherein the file system is included in a backup. Block 520 can include generating, by the file system scanner, a read buffer to store logical blocks of files included in the file system. Block 530 can include determining, by a block filter driver executed by the controller, whether the read buffer includes a predefined signature indicative of a block change detection operation.

[0051] Block 540 can include determining, by the block filter driver, whether the logical block was modified in the backup in response to determining that the read buffer includes the predefined signature. Block 550 can include setting, by the block filter driver, a modification flag in the read buffer to a value indicative of the logical block being modified in response to determining that the logical block was modified in the backup. Blocks 510-550 can generally correspond to the example described above with reference to instructions 410-450 (as shown in FIG. 4). Figure 4

[0052] Figure 6 - example machine-readable medium

[0053] Figure 6 A machine-readable medium 600 having instructions 610-650 stored therein is shown in accordance with some embodiments. The instructions 610-650 can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, and the like. The machine-readable medium 600 can be a non-transitory storage medium such as an optical storage medium, a semiconductor storage medium, or a magnetic storage medium. The instructions 610-650 can generally correspond to the example described above with reference to instructions 410-450 (as shown in FIG. 4). Figure 4

[0054] ​​Instruction 610 can be executed to identify, by the file system scanner, a plurality of files included in a file system, wherein each file in the file system includes one or more logical blocks, and wherein the file system is included in a backup. Instruction 620 can be executed to generate, by the file system scanner, a read buffer to store a logical block of a file included in the file system. Instruction 630 can be executed to determine, by the block filter driver, whether the read buffer includes a predefined signature indicative of a block change detection operation.

[0055] Instruction 640 can be executed to determine, by the block filter driver, whether the logical block was modified in the backup in response to determining that the read buffer includes the predefined signature. Instruction 650 can be executed to set, by the block filter driver, a modification flag in the read buffer to a value indicative of the logical block being modified in response to determining that the logical block was modified in the backup.

[0056] Conclusion

[0057] According to some embodiments described herein, a computing device can execute a file system scanner and a block filter driver to determine which files and data blocks were modified in a particular backup. The file system scanner can identify each file in a file system and can issue read calls to retrieve data blocks in the identified files. Further, the file system scanner can write a special signature into a read buffer for the read calls. The block filter driver can intercept each read call and, in response, can determine whether the special signature is present in the read buffer associated with the read call. If the special signature is present in the read buffer, the block filter driver determines whether the requested data block was modified in the most recent backup. In some embodiments, the block change detection operation can involve performing a lookup for the requested data block in a changed block data structure. Subsequently, the block filter driver can populate the read buffer with block change information indicative of which data blocks, if any, were modified in the backup. The file system scanner can obtain the block change information from the read buffer and can use the information to generate a modification report. In this way, some embodiments can provide block change information that identifies modifications to a file system that occurred at the data block level and that was generated in a way that is not subject to timestamp manipulation by malware.

[0058] Note that, although Figures 1-6 Various examples are illustrated, but the embodiments are not limited in this regard. For example, the example of FIG. 1 is merely illustrative of one example of a system that can be used in conjunction with the embodiments described herein. Other systems can be used without departing from the scope of the embodiments. Figure 1 It is contemplated that system 100 can include additional devices and / or components, fewer components, different components, different arrangements, etc. In another example, it is contemplated that the functionality of computing device 110 described above can be included in any other engine or software of system 100. Other combinations and / or variations are also possible.

[0059] Data and instructions are stored in respective storage devices, which are implemented as one or more computer-readable or machine-readable storage media. The storage media include different forms of memory including semiconductor memory devices, such as dynamic or static random access memories (DRAMs or SRAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices.

[0060] Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media in distributed systems. Such one or more computer-readable or machine-readable storage media are considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to one or more computer programs, one or more computer-readable or machine-readable storage media, or one or more non-transitory computer-readable or machine-readable storage media having the computer-readable or machine-readable program code embodied thereon or therein. The one or more computer-readable or machine-readable storage media can be located in a single site, or distributed over multiple sites.

[0061] In the foregoing description, numerous details are set forth to facilitate understanding. Implementations can be practiced without some or all of these details. Other implementations can include modifications and changes to the details discussed above. The accompanying claims are intended to cover such modifications and changes.

[0062] In this disclosure, the use of the term “a” or “an” is intended to mean “one,” but also “more than one.” Likewise, the term “the” is intended to mean “the one,” but also “the more than one.” Also, the use of the term “includes” or “comprises” or “comprising” or “having” is intended to mean that there are other items or components being included or comprising, but that these items or components are not exhaustive of the items or components, more items or components can be conceived based on this disclosure.

Claims

1. A computing device comprising: a controller; and a machine-readable storage device storing instructions executable by the processor to: identify, by a file system scanner, a plurality of files included in a file system, wherein each file in the file system comprises one or more logical blocks, and wherein the file system is included in a backup; generate, by the file system scanner, a read buffer to store a logical block of a file included in the file system; determine, by a block filter driver, whether the read buffer includes a predefined signature indicative of a block change detection operation; in response to determining that the read buffer includes the predefined signature, determine, by the block filter driver, whether the logical block was modified in the backup; and in response to determining that the logical block was modified in the backup, set, by the block filter driver, a modified flag in the read buffer to a value indicative that the logical block was modified.

2. The computing device of claim 1, comprising instructions executable by the processor to: mount, by the file system scanner, the file system at a memory location; issue, by the file system scanner, a read call for the logical block; and convert, by the mounted file system, the logical block in the read call to a physical block.

3. The computing device of claim 2, comprising instructions executable by the processor to: receive, by the block filter driver, a converted read call for the physical block from the mounted file system; and in response to receiving the converted read call for the physical block, determine, by the block filter driver, whether the read buffer includes the predefined signature.

4. The computing device of claim 3, comprising instructions executable by the processor to: in response to determining that the read buffer includes the predefined signature, perform a lookup for the physical block in a modified block data structure associated with the backup; and determine whether the logical block was modified in the backup based on the lookup for the physical block in the modified block data structure. the modified block data structure is a modified block bitmap generated with the backup.

5. The computing device of claim 4, wherein, 6. The computing device of claim 2, comprising instructions executable by the processor to: prior to issuing the read call, issue, by the file system scanner, an open system call for the file using a command flag to invoke a direct input / output (I / O) mode. the read buffer is one of a plurality of read buffers generated by the file system scanner, and wherein each of the plurality of read buffers corresponds to a different logical block requested by the read call.

7. The computing device of claim 2, wherein, 8. The computing device of claim 2, comprising instructions executable by the processor to: ​ in response to determining that the read buffer does not include the predefined signature, obtaining the physical block from persistent storage; and populating the obtained physical block into the read buffer.

9. The computing device of claim 1, wherein, the file system scanner is executed in a user space of a system memory, and wherein the block filter driver is executed in a kernel space of the system memory.

10. A method comprising: identifying, by a file system scanner executed by a controller, a plurality of files included in a file system, wherein each file in the file system includes one or more logical blocks, and wherein the file system is included in a backup; generating, by the file system scanner, a read buffer to store logical blocks of files included in the file system; determining, by a block filter driver executed by the controller, whether the read buffer includes a predefined signature indicative of a block change detection operation; in response to determining that the read buffer includes the predefined signature, determining, by the block filter driver, whether the logical block was modified in the backup; and in response to determining that the logical block was modified in the backup, setting, by the block filter driver, a modification flag in the read buffer to a value indicative that the logical block was modified.

11. The method of claim 10, comprising: mounting, by the file system scanner, the file system at a memory location; issuing, by the file system scanner, a read call for the logical block; and converting, by the mounted file system, the logical block in the read call to a physical block.

12. The method of claim 11, comprising: receiving, by the block filter driver, a converted read call for the physical block from the mounted file system; and in response to receiving the converted read call for the physical block, determining, by the block filter driver, whether the read buffer includes the predefined signature.

13. The method of claim 12, comprising: in response to determining that the read buffer includes the predefined signature, performing a lookup for the physical block in a changed block data structure associated with the backup; and determining whether the logical block was modified in the backup based on the lookup for the physical block in the changed block data structure.

14. The method of claim 11, comprising: prior to issuing the read call, issuing, by the file system scanner, an open system call for the file using a command flag to invoke a direct input / output (I / O) mode.

15. The method of claim 11, comprising: in response to determining that the read buffer does not include the predefined signature, obtaining the physical block from persistent storage; and populating the obtained physical block into the read buffer.

16. A non-transitory machine-readable medium storing instructions that, when executed, cause a controller to: each file in the file system includes one or more logical blocks, and wherein the file system is included in a backup; identifying, by a file system scanner, a plurality of files included in a file system, wherein, ​ generating, by the file system scanner, a read buffer to store a logical block of a file included in the file system; determining, by the block filter driver, whether the read buffer includes a predefined signature indicative of a block change detection operation; in response to determining that the read buffer includes the predefined signature, determining, by the block filter driver, whether the logical block was modified in the backup; and in response to determining that the logical block was modified in the backup, setting, by the block filter driver, a modified flag in the read buffer to a value indicative that the logical block was modified.

17. The non-transitory machine-readable medium of claim 16, comprising instructions that, when executed, cause the controller to: mount, by the file system scanner, the file system at a memory location; issue, by the file system scanner, a read call for the logical block; and convert, by the mounted file system, the logical block in the read call to a physical block.

18. The non-transitory machine-readable medium of claim 17, comprising instructions that, when executed, cause the controller to: receive, by the block filter driver, a converted read call for the physical block from the mounted file system; and in response to receiving the converted read call for the physical block, determine, by the block filter driver, whether the read buffer includes the predefined signature.

19. The non-transitory machine-readable medium of claim 18, comprising instructions that, when executed, cause the controller to: in response to determining that the read buffer includes the predefined signature, perform a lookup for the physical block in an altered block data structure associated with the backup; and determine whether the logical block was modified in the backup based on the lookup for the physical block in the altered block data structure.

20. The non-transitory machine-readable medium of claim 17, comprising instructions that, when executed, cause the controller to: in response to determining that the read buffer does not include the predefined signature, obtain the physical block from persistent storage; and populate the obtained physical block into the read buffer.

Images