Patent Description:
Typically, the backup and storage of archives for recovery is performed regularly according to a schedule. It is often the case that the backup may become tainted with malicious software, therefore companies often have automated software that performs malware scans, either prior to backup, during backup, prior to restoration or the like. Virus and malware scans should be carried out periodically and regularly because anti-virus databases are updated often due to the emergence of new types of malware. However, full scanning of large archives requires considerable time and computational resources, often not available or not an efficient use of the time and resources. Scanning archives becomes especially critical if the archives are not stored locally, but in cloud storage, because the speed of access to an archive in the cloud may be significantly slower than accessing a local storage device (depending on the speed of the network or communication channel being used, and/or how heavily the channel is loaded). Additionally, if any problems arise such that viruses and/or malicious files are found in the archive, the archive is considered damaged or infected, and may not be entirely suitable for use in system recovery or file and data extraction. Conventionally, to avoid restoring data that is infected, archives are periodically scanned with anti-virus scanners during storage, when new slices are added to the archive and/or before restoring the data. However, currently there is no solution to scan arbitrary time points in an archive. Instead, solutions are forced to scan the entire archive. Furthermore, currently damaged or infected data in archives cannot be repaired. Examples of known system and method for scanning malware are disclosed in the following prior art documents <CIT>, <CIT> and "<NPL>.

Aspects of the disclosure relate to the field of virus and malware detection in stored archives. In particular, aspects of the disclosure describe methods and systems for scanning backup archives by inspecting slices of the archive.

In one example, the method comprises generating a backup slice that reflects a state of data at a first time, wherein the backup slice is stored in a backup archive. The method comprises generating a virtual volume comprising a list of files in the backup slice and associated file information, wherein the virtual volume does not store the files referenced in the list of files. The method comprises mounting the virtual volume to a disk. The method comprises creating, in the virtual volume, empty sparse files that are placeholders of the files reference in the list of files. The method comprises for each respective empty sparse file: comparing file information associated with the respective empty sparse file with file information associated with a corresponding file in another backup slice reflecting the state of data at a second time, and in response to detecting a change between the respective empty sparse file and the corresponding file: retrieving content associated with the respective empty sparse file from the backup slice; and storing the content in the virtual volume in place of the respective empty sparse file. The method comprises scanning the virtual volume for viruses and/or malicious software. The method comprises in response to detecting that at least one file in the virtual volume is infected with a virus and/or malicious software, generating a cured slice that replaces the backup slice in the backup archive.

In some examples, the first time is after the second time.

In some examples, the virtual volume is generated by a virtual volume driver.

In some examples, the associated file information comprises at least one of: (<NUM>) a file number of a respective file in the list, (<NUM>) a location of the respective file in the backup slice, and (<NUM>) a file size of the respective file.

In some examples, generating the cured slice comprises removing the at least one file from the mounted virtual volume.

In some examples, generating the cured slice comprises generating a copy of the backup slice, and transferring, to the copy of the backup slice, all unchanged files in the list of files and not including the at least one file, wherein the copy of the backup slice is the cured slice.

In some examples, the virtual volume is mounted to the disk subsequent to or concurrently with another virtual volume associated with the another backup slice.

In some examples, adding the cured slice to the backup archive.

It should be noted that the methods described above may be implemented in a system comprising a hardware processor. Alternatively, the methods may be implemented using computer executable instructions of a non-transitory computer readable medium.

The above simplified summary of example aspects serves to provide a basic understanding of the present disclosure. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects of the present disclosure. Its sole purpose is to present one or more aspects in a simplified form as a prelude to the more detailed description of the disclosure that follows. To the accomplishment of the foregoing, the one or more aspects of the present disclosure include the features described and exemplarily pointed out in the claims.

Exemplary aspects are described herein in the context of a system, method, and computer program product for inspecting archive slices for malware. Those of ordinary skill in the art will realize that the following description is illustrative only and is not intended to be in any way limiting. Other aspects will readily suggest themselves to those skilled in the art having the benefit of this disclosure. Reference will now be made in detail to implementations of the example aspects as illustrated in the accompanying drawings. The same reference indicators will be used to the extent possible throughout the drawings and the following description to refer to the same or like items.

<FIG> is a block diagram of a system <NUM> of scanning backup archives by inspecting archive slices, in accordance with exemplary aspects of the present disclosure.

The system <NUM> comprises a computing device <NUM>, an archive scanner <NUM>, a disk <NUM>, and a cloud archive <NUM>. The client computing device <NUM> may be any type of mobile computing device such as a laptop computer, a tablet computer, a mobile device, or the like. The computing device <NUM> also includes a backup module <NUM> that performs a backup of user data stored on the computing device <NUM>, wherein the user data may include an entire backup image of the disks of the computing device <NUM>, software installed on the device <NUM>, user application data such as personal documents, or the like.

The backup module <NUM> may also retrieve data that is not stored locally at the computing device <NUM>. In one example, the backup module <NUM> stores and/or retrieves user data as a set of backup slices <NUM> to/from a cloud archive <NUM>, or alternatively, a local archive on a physical disk associated with the computing device <NUM>. The backup slices <NUM> are collectively stored in backup archives <NUM> in the cloud archive <NUM>. Each backup slice is an image of the user data or physical disk of the computing device <NUM> at a particular moment in time. Over time, the cloud archive <NUM> contains many backup archives <NUM> for different computing devices, each with multiple backup slices.

The backup module <NUM> communicates with the cloud archive <NUM> over a network <NUM> (e.g., the Internet). In some instances, if the backup module <NUM> would like to restore data from the backup archives <NUM>, a scan would be performed. When the backup archives <NUM> have grown considerably in size (e.g., beyond a predetermined threshold such as <NUM> GB), requesting a scan to be performed may take a significant amount of time and resources. In the case where the archives <NUM> are stored locally, the backup module <NUM> may take up a significant amount of resources of the computing device <NUM> that may be needed elsewhere. Such resources may include storage space, memory (e.g., RAM), and processing power.

In order to avoid excessive consumption of resources, whether locally and/or at a cloud platform, the cloud archive <NUM> is subjected to periodic scanning by the archive scanner <NUM>. The archive scanner <NUM> comprises an archive mounter service <NUM>, an archive API <NUM> and an archive mount driver <NUM>. In some examples, the archive scanner <NUM> is executing as a service over the network <NUM>, though in other examples, the archive scanner <NUM> may be executing on the computing device <NUM>. Furthermore, other configurations are contemplated where the archive scanner may operate on a different server or on the same server as the cloud archive <NUM>.

The archive scanner <NUM> performs antivirus and malware scans on the backup archives <NUM> to ensure that when data is retrieved from the cloud archive, a computing device such as computing device <NUM> does not accidentally become infected. The device (e.g., a server) that is executing the archive scanner <NUM> may have a physical disk <NUM>. In one example, the device may comprise a host machine and a virtual machine. The archive scanner <NUM> receives a request to scan the backup archives <NUM>. The archive API <NUM> is used to retrieve new and modified blocks from the slices stored in the backup archives <NUM>. The archive mount driver <NUM> receives a request to mount an archive slice from the backup archives <NUM>, allowing the archive scanner <NUM> to work with the archive as a disk. The archive mount driver <NUM> may mount the archive slice as virtual disk <NUM>. The archive mount driver <NUM> allows the ability to save changes to the data in the mounted slice if changes were made, according to some aspects.

In one example, the archive scanner <NUM> detects all modified blocks in the most recent slices since creation of the most recent slice. Subsequently, the archive scanner <NUM> uses the archive API <NUM> to determining a correspondence of files in the one or more slice with data blocks on the mounted disk. Such a determination may be made using a block map. Once the correspondence has been created, the files on the mounted virtual disk <NUM> that align with the modified blocks are also assumed to either be new or modified. Thus, these new files on the virtual disk <NUM> can be scanned for infection, viruses and malicious software. The archive API <NUM> can be further invoked by the archive scanner <NUM> to remove infected and/or damaged files and malware from the virtual disk <NUM>. Finally, the archive scanner <NUM> can save the virtual disk <NUM> as a new cured slice in the backup archives <NUM> stored in the cloud archive <NUM> (or stored on a storage device local to computing device <NUM>). In some other examples, the existing slice may be removed and replaced with the new cured slice.

Aspects for forming the block map depend on the particular OS and file system. For example, in Windows NTFS files can be master file table (MFT) resident (stored inside MFT records) or non-resident, stored in the volume storage space. In one example, the allocated blocks of the non-resident file may be retrieved using a system function call, e.g., "FSCTL_GET_RETRIEVAL_POINTERS API". MFT resident files block maps may be determined with the analysis of the MFT allocation and the known file identifier, which is generally the MFT record number. The MFT record number allows inspection and knowledge of the blocks of the MFT resident file. The analysis of the MFT allocation can also be determined with the help of system function "FSCTL_GET_RETRIEVAL_POINTERS" for example, but for the entire MFT, which is also a file. Other file systems can require their own special algorithms that build the files block map(s).

The archive scanner <NUM> may also be configured to scan one or more older slices in the backup archive <NUM> in order to discover an infected slice. Once such an infected or otherwise compromised slice is identified, the archive scanner <NUM> marks the infected slice and slices taken subsequently (temporally) as infected and unsuitable for data recovery for any computing device. Accordingly, the backup module <NUM> is configured to block any attempts to restore slices that are marked as infected. Furthermore, this allows the archive scanner <NUM> to establish a time of compromise that can be used for further analysis regarding the type of infection and the factors that may have been involved in the compromise. In some examples, historical attributes of the computing device <NUM> can be stored in the cloud archive <NUM>, or elsewhere, and analyzed along with the time of compromise to establish a set of causes of the compromise/infection. This analysis can be used to prevent future infections or malware attacks.

<FIG> is a block diagram illustrating the sequence of the system and method of scanning backup archives by inspecting archive slices.

In one example, the archive mounter service <NUM>, the archive API <NUM> and the cloud archive <NUM> and the local archive <NUM> may be located in the user memory space (UM), while the archive mount driver <NUM> may be located in kernel memory space (KM). In order to access the cloud archive <NUM> or a local archive <NUM>, the archive scanner <NUM> contacts the archive mounter service <NUM>. The archive mounter service <NUM> uses the mount driver <NUM> to mount the archives to a disk (e.g., a virtual disk).

Referring to <FIG>, mount driver <NUM> mounts, to disk <NUM>, a first slice <NUM> of a plurality of slices (e.g., slices <NUM>-<NUM>) in cloud archive <NUM>, wherein the first slice is an image of user data (e.g., on computing device <NUM>) at a first time. Archive API <NUM> then detects a modified block of the mounted first slice by comparing blocks of the mounted first slice to blocks of a second slice <NUM> of the plurality of slices, wherein the second slice is an image of the user data captured before the first time. For example, first slice <NUM> may have been created at time t. Second slice <NUM> may have been created at time t-<NUM>.

Archive API <NUM> may then compare the blocks of the respective mounted disks of the respective slices to find blocks that have been altered. When a modified block is found, archive mounter service <NUM> identifies, on a file system of the disk, at least one file in the mounted first slice that corresponds to the detected modified block. Archive scanner <NUM> then scans the at least one file for viruses and malicious software. In response to detecting that the at least one file is infected, archive scanner <NUM> generates a cured slice that comprises the user data of the mounted first slice without the at least one file. This generation process may comprise removing the at least one file from the mounted first slice <NUM>. In some cases, where multiple modified blocks are found in slice <NUM> relative to slice <NUM>, the generation process involves generating a copy of the second slice <NUM>, transferring, to the copy of the second slice, all files corresponding to the plurality of modified blocks and not including any infected file (here, the copy of the second slice is the cured slice).

In some examples, archive scanner <NUM> may arbitrarily scan a third slice <NUM> of the plurality of slices in the backup archive for viruses and malicious software. The third slice <NUM> may be an image of the user data captured before a creation time of the second slice (i.e., t-N). In response to detecting an infected file in the third slice <NUM>, archive scanner <NUM> may mark a subset of the plurality of slices captured subsequent to a creation time of the third slice as unsuitable for data recovery. In this particular example, both first slice <NUM> and the second slice <NUM> would be included in the subset.

In some examples, archive scanner <NUM> may identify a block of the third slice <NUM> that corresponds to the infected file. Archive scanner <NUM> may mount the second slice <NUM> and the first slice <NUM> to the disk <NUM>. Archive scanner <NUM> may track the block and determine whether the infected file exists on any one of the second slice and the first slice. For example, the infected file may exist on second slice <NUM>, but the user may have manually removed the infected file from first slice <NUM>. Because the infected file does not exist on first slice <NUM>, only the third slice <NUM> and the second slice <NUM> need to be cured. This will ensure that the backup archive has a clean set of slices that a user can back up from.

In some examples, if the archive contains infected slices, the archive scanner <NUM> may discover these slices to determine when infection occurred (based on slice creation time) and the source of the infection or malware by scanning the slices.

<FIG> is block diagram <NUM> of inspecting archive slices for malware using empty sparse files. Diagram <NUM> introduces HSM archive file system filter driver <NUM> and virtual volume driver <NUM>. Antivirus scanning of backups stored in the cloud is usually a very time-consuming procedure that requires a lot of hardware resources. This is due to the fact that cloud storage usually contains large amounts of data, the speed of access to the cloud is significantly slower than to local storage, and at the same time, backups must be scanned quite often.

The present disclosure previously described technology that is applicable to image archives when the data is backed up on a sector-by-sector basis. However, there are file-only archives as well as archives of a different nature (e.g., databases, e-mail archives, etc.), and working with such objects at the block sector level may be ineffective. Currently, arbitrary time points in the archive can be scanned and can fix the latest slice or mark older as not suitable for recovery. However, this functionality is limited to image archives and does not apply to file archives.

Accordingly, virtual volume driver <NUM> and the HSM archive file system filter driver <NUM> are utilized to provide access to any slice of file archives and any files on them to further scan the slices and remove malicious / infected files. From a high-level overview, slices can be mounted, using virtual volume driver <NUM>, in the archives (cloud or local) as empty (e.g., no files). More specifically, the mounted slice is populated with empty zero data files (but with proper virtual sizes). When an AV scan is performed, and it can be performed on specific files, HSM filter driver <NUM> fetches the data on access and fills the scanned file. In the latest slice, infected data and malware can be removed and the latest slice can be recreated with the fixed data for potential restore/recovery.

It should be noted that access to slices of the cloud file archive is accomplished using the appropriate API (e.g., API <NUM>). The mounted virtual volume comprises empty sparse files on the given volume, but reproduces the structure of the backup slice it is based on and contains information about the files in it. Archive API <NUM> may track requests to read a file from antivirus software and retrieve the contents of this file from the backup archive in case of a read request. From here, archive scanner <NUM> may scan received files in virtual volume, delete infected files, and recreate the last slice of the archive.

As discussed previously, cloud archive <NUM> and local archive <NUM> contain data backups (used interchangeably with "backup archives") with files. A user may regularly perform backups of their computing devices and all the changed files are sent to the archives. In terms of performing backups, it should be understood that the first backup is of all files and all subsequent backups are incremental (only new and modified files are copied). Each backup session results in a separate backup slice, which reflects the state of the data at a certain point in time.

Virtual volume driver <NUM> creates empty volumes for each backup slice. These volumes are later scanned for malware. Such volumes are virtual and do not contain any data aside from a list of files in a respective backup slice and relevant file information (e.g., name, number, size, location, metadata, etc.). The real data is in fact stored in the real backup slice in the backup archive. This allows for scanning a file backup archive in the cloud.

Virtual volume driver <NUM> mounts the virtual volume, which fully displays the structure of the physical slice despite not containing the actual data. Subsequently, a hierarchical filter driver, HSM archive file system filter driver <NUM>, creates empty sparse files that match the actual files in the backup slice. Here, access to specific files can be implemented without need to access the entire file system as a whole.

Driver <NUM> provides access to the contents of a file, compares changes between files in two different slices, and if there are such changes, downloads the contents of the file from the archive in the cloud. Driver <NUM> then places the contents, in the virtual volume, in the placeholder corresponding to this file (e.g., the empty sparse file).

Thus, only a set of files that changed between the creation of two sequential slices are considered. In the latest slice, infected data and malware can be removed and a new slice can be created (i.e., a cured slice) with the fixed data for potential restore/recovery. These systems and methods help to work with specific objects such as databases or email archives, which can be represented in the virtual volume as file entities.

As discussed previously, archive API <NUM> can be used to get access to a backup archive (either cloud and/or local). Archive API <NUM> can be specific to any type of archive and storage, and is used to understand the content and structure of a certain archive (because these can be different depending on different vendors of backup and storage software and hardware).

<FIG> is a flowchart illustrating a method <NUM> of scanning backup archives by inspecting archive slices.

The method begins at <NUM> and proceeds to <NUM>.

At <NUM>, components of the archive scanner <NUM> scan the backup archives by inspecting archive slices. Components of the archive scanner mount a most recent slice from a backup archive to a disk, e.g., by mounting a virtual disk. In some examples, a virtual disk may be mounted on a server executing the archive scanner <NUM>, though the present disclosure is not limited to that configuration.

At <NUM>, the archive API <NUM> is requested to detect all modified blocks in the most recent slices since creation of the most recent slice. In some examples, the API <NUM> inspects the underlying blocks of the virtual disk that the slice is mounted to, in order to determine the modified blocks. In other examples, the modified blocks are detected by comparing blocks of the most recent slice to blocks of previously created slices for previous backups of a computing device. The blocks that differ from one slice to the next comprises the modified set of blocks.

At <NUM>, the archive scanner <NUM> determines a correspondence of files in the one or more slice with data blocks on the mounted disk. In some examples, the archive scanner <NUM> establishes or reads the block map of the particular backup slice being mounted, where the block map indicates which blocks correspond to which files.

At <NUM>, the archive scanner <NUM> determines on the file system of the disk, the files that have been modified by identifying the modified data blocks. Since the modified data blocks have been identified, the block can be used to identify which files corresponding to the modified data blocks.

At <NUM>, the archive scanner <NUM> scans the files on the file system that have been modified since a previous backup slice was completed for viruses and malicious software.

At <NUM>, the archive scanner <NUM> may remove infected and/or damaged files and malware from the virtual disk. The virtual disk can then be saved as the most recent slice and reinserted into the backup archives <NUM> in the cloud archive <NUM>, or at a local disk.

<FIG> is a flowchart illustrating another method <NUM> of scanning backup archives by inspecting archive slices.

At <NUM>, the archive scanner <NUM> scans the backup image mounted on the virtual disk in method <NUM>. In one example, the backup image or the archive image as it may be referred to, may be mounted as a virtual disk or, in other examples, restoring the slice to a physical disk.

At <NUM>, the files that are infected are identified and marked. In some examples the files are identified based on the modified blocks identified in method <NUM> using a block map or other method. The block map shows a correspondence between blocks and files on the mounted image. Thus when the modified blocks are identified, the archive scanner <NUM> can identify the modified files.

At <NUM>, any malware present on the mounted backup image is identified by performing a virus and malware scan on the files on the virtual disk.

At <NUM>, the infected files and malware are removed from the file system of the disk (e.g., a virtual disk) by the archive scanner <NUM>. In some examples, the infected files and/or malware is quarantined, either on the virtual disk or elsewhere. It should be noted that moving infected files to a quarantine on the virtual disk requires creating the cured slice that comprises the quarantine.

At <NUM>, a new slice is created by the archive scanner <NUM>, excluding the infected files and malware by exporting the virtual disk as a new slice. The new slice is either stored on a new virtual disk or in another location such as the virtual disk <NUM>, or in a cloud archive <NUM> as shown in <FIG> (e.g., latest slice <NUM>).

At <NUM>, the archive scanner adds the newly created and cured slice on top of the most recent slice in the backup archive (e.g., archive <NUM>). In some examples, the newly created slice may replace the most recent slice or the infected slice.

<FIG> is a flowchart illustrating method <NUM> of inspecting archive slices for malware using empty sparse files. At <NUM>, a backup slice is generated that reflects a state of data at a first time, wherein the backup slice is stored in a backup archive (e.g., archive <NUM> and/or archive <NUM>). At <NUM>, virtual volume driver <NUM> generates a virtual volume comprising a list of files in the backup slice and associated file information, wherein the virtual volume does not store the files referenced in the list of files. At <NUM>, archive mounter service <NUM> mounts the virtual volume to disk <NUM>. At <NUM>, HSM archive file system filter driver <NUM> creates, in the virtual volume, empty sparse files <NUM> that are placeholders of the files reference in the list of files.

Suppose that there are N files in the list of files. At <NUM>, archive API <NUM> identifies a respective empty sparse file. At <NUM>, archive API <NUM> detects where there is a change between the respective empty sparse file and a corresponding file in another backup slice reflecting the state of data at a second time. For example, archive API <NUM> may compare file information associated with the respective empty sparse file with file information associated with the corresponding file in the another backup slice (e.g., compare names, sizes, metadata, etc.).

In response to detecting a change between the respective empty sparse file and the corresponding file, method <NUM> advances to <NUM>, where driver <NUM> retrieves content associated with the respective empty sparse file from the backup slice. At <NUM>, driver <NUM> stores the content in the virtual volume in place of the respective empty sparse file.

Method <NUM> then advances to <NUM>, where archive API <NUM> determines if there are other empty sparse files to consider from the list (i.e., all files in the list are checked for changes). If more sparse files remain, method <NUM> returns to <NUM> where the next sparse file is identified. Otherwise, method <NUM> advances to <NUM>, where archive scanner <NUM> scans the virtual volume for viruses and/or malicious software.

At <NUM>, archive scanner <NUM> determines whether there is at least one file in the virtual volume infected with a virus and/or malicious software. If there are no infected files, method <NUM> ends at <NUM>. However, in response to detecting that at least one file in the virtual volume is infected with a virus and/or malicious software, at <NUM>, archive scanner <NUM> generates a cured slice that replaces the backup slice in the backup archive.

<FIG> is a block diagram illustrating a computer system <NUM> on which examples of systems and methods of scanning backup archives by inspecting archive slices may be implemented. It should be noted that the computer system <NUM> can correspond to any components of the system <NUM> described earlier. The computer system <NUM> can be in the form of multiple computing devices, or in the form of a single computing device, for example, a desktop computer, a notebook computer, a laptop computer, a mobile computing device, a smart phone, a tablet computer, a server, a mainframe, an embedded device, and other forms of computing devices.

As shown, the computer system <NUM> includes a central processing unit (CPU) <NUM>, a system memory <NUM>, and a system bus <NUM> connecting the various system components, including the memory associated with the central processing unit <NUM>. The system bus <NUM> may comprise a bus memory or bus memory controller, a peripheral bus, and a local bus that is able to interact with any other bus architecture. Examples of the buses may include PCI, ISA, PCI-Express, HyperTransport™, InfiniBand™, Serial ATA, I<NUM>C, and other suitable interconnects. The central processing unit <NUM> (also referred to as a processor) can include a single or multiple sets of processors having single or multiple cores. The processor <NUM> may execute one or more computer-executable codes implementing the techniques of the present disclosure. The system memory <NUM> may be any memory for storing data used herein and/or computer programs that are executable by the processor <NUM>. The system memory <NUM> may include volatile memory such as a random access memory (RAM) <NUM> and non-volatile memory such as a read only memory (ROM) <NUM>, flash memory, etc., or any combination thereof. The basic input/output system (BIOS) <NUM> may store the basic procedures for transfer of information between elements of the computer system <NUM>, such as those at the time of loading the operating system with the use of the ROM <NUM>.

In addition to the display devices <NUM>, the computer system <NUM> may be equipped with other peripheral output devices (not shown), such as loudspeakers and other audiovisual devices
The computer system <NUM> may operate in a network environment, using a network connection to one or more remote computers <NUM>.

The computer readable storage medium can be a tangible device that can retain and store program code in the form of instructions or data structures that can be accessed by a processor of a computing device, such as the computer system <NUM>.

Computer readable program instructions for carrying out operations of the present disclosure may be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language, and conventional procedural programming languages. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a LAN or WAN, or the connection may be made to an external computer (for example, through the Internet). In some examples, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

In various examples, the systems and methods described in the present disclosure can be addressed in terms of modules. The term "module" as used herein refers to a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or FPGA, for example, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device. A module may also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of a module may be executed on the processor of a computer system (such as the one described in greater detail in <FIG>). Accordingly, each module may be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein.

Furthermore, it is to be understood that the phraseology or terminology used herein is for the purpose of description and not of restriction, such that the terminology or phraseology of the present specification is to be interpreted by the skilled in the art in light of the teachings and guidance presented herein, in combination with the knowledge of the skilled in the relevant art(s). Moreover, it is not intended for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such.

Claim 1:
A method (<NUM>) for inspecting archive slices for malware, the method comprising:
generating (<NUM>) a backup slice that reflects a state of data at a first time, wherein the backup slice is stored in a backup archive;
generating (<NUM>) a virtual volume comprising a list of files in the backup slice and associated file information, wherein the virtual volume does not store the files referenced in the list of files;
mounting (<NUM>) the virtual volume to a disk;
creating (<NUM>), in the virtual volume, empty sparse files that are placeholders of the files referenced in the list of files;
for each respective empty sparse file:
comparing (<NUM>) file information associated with the respective empty sparse file with file information associated with a corresponding file in another backup slice reflecting the state of data at a second time; and
in response to detecting a change between the respective empty sparse file and the corresponding file:
retrieving (<NUM>) content associated with the respective empty sparse file from the backup slice; and
storing (<NUM>) the content in the virtual volume in place of the respective empty sparse file;
scanning (<NUM>) the virtual volume for viruses and/or malicious software; and
in response to detecting that at least one file in the virtual volume is infected with a virus and/or malicious software, generating (<NUM>) a cured slice that replaces the backup slice in the backup archive.