Delta anomaly detection in security copies of specialized directory services assets

Abstract

A procedure for managing access to a file-based backup (FBB) includes, at a first time point, generating a first FBB at a first time point, wherein the first FBB comprises a first set of files of an asset at the first time point; generating a second FBB at a second time point after the first time point, wherein the second FBB comprises a second set of files of the asset at the second time point; performing asset analysis on the first FBB metadata file and a second FBB metadata file associated with the second FBB to generate a differentiating FBB metadata file; performing anomaly analysis on the second FBB using the differentiating FBB metadata file to obtain an anomaly report; and performing problem correction on the second FBB based on the anomaly report.

Description

GENERAL STATE OF THE ART

[0001] Computing devices in a system can include any number of internal components, such as processors, memory, and persistent storage. Storing data across multiple computing devices can require significant use of such internal components. Deduplicating such data before storage can improve the overall operation of such computing devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain embodiments of the invention will be described in detail with reference to the accompanying drawings. However, the accompanying drawings only illustrate certain aspects or implementations of the invention by way of example and are not intended to limit the scope of the claims. Fig. 1 shows a schematic representation of a system according to one or more embodiments of the invention. Fig. 2 shows a schematic representation of a file-based backup (FBB) according to one or more embodiments of the invention. Fig. 3A shows a flowchart for managing backup policies of a set of sub-assets according to one or more embodiments of the invention. Fig. 3B shows a first example according to one or more embodiments of the invention. Fig. 4A shows a flowchart for managing proactive asset recovery according to one or more embodiments of the invention. Fig. 4B shows a second example according to one or more embodiments of the invention. Fig. 5A shows a flowchart for performing delta anomaly detection for security protection according to one or more embodiments of the invention. Fig. 5B shows an example according to one or more embodiments of the invention. Fig. 6 shows a schematic representation of a computing device according to one or more embodiments of the invention. DETAILED DESCRIPTION

[0003] Specific embodiments will now be described with reference to the accompanying figures. In the following description, numerous details are given as examples of the invention. It will be understood by those skilled in the art that one or more embodiments of the present invention may be practiced without these specific details, and that numerous variations or modifications are possible without departing from the scope of the invention. Certain details known to those skilled in the art have been omitted in order not to obscure the description.

[0004] In the following description of the figures, each component described with respect to one figure may, in various embodiments of the invention, be equivalent to one or more like-named components described with respect to another figure. For brevity, descriptions of these components are not repeated for each figure. Therefore, each individual embodiment of the components of each figure is incorporated by reference and is deemed to be optionally present in any other figure having one or more like-named components. Furthermore, in accordance with various embodiments of the invention, each description of the components of a figure is to be understood as an optional embodiment that may be implemented in addition to, in conjunction with, or instead of the embodiments described with respect to a corresponding like-named component in another figure.

[0005] In general, embodiments of the invention relate to a method and system for managing file-based backups. Embodiments of the invention relate to a system for using a file-based backup (FBB) metadata file of an FBB stored in a backup storage system to enable access to the FBB data by managing the file system corresponding to the FBB. The application may operate from a production host environment operatively connected to the backup storage system. The FBB metadata file may be utilized by obtaining the attributes corresponding to the data in the FBB, including the location, file name, and file size, and enabling access to these attributes by the applications.An FBB metadata file manager running on the production host environment can use the obtained attributes to enable access to the data (e.g., files) in the FBB by the logins. For example, the FBB metadata file manager can implement a virtual file system that specifies the files in the file-based backup and their location in the backup storage system.

[0006] The embodiments disclosed herein address the use case of using different post-backup retention periods and / or levels for the various data segments of a large asset backed up as composite data. The embodiments disclosed herein include reducing the complexity of managing multiple schedulers, policies, and distributions before and during backup creation. Once a backup is created, sub-assets are dynamically created based on the attributes of the assets (e.g., whether the asset is associated with a specific directory service). Each sub-asset can have different retention levels.For example, an entire file system can be protected as a single asset, but after backup, specialized directory service and non-specialized directory service data can be intelligently separated, creating sub-assets. These sub-assets can then be assigned different retention and classification policies based on data importance and user preferences.

[0007] The embodiments disclosed herein further include methods and systems that enable predictive recovery of data associated with a specialized directory service. A specialized directory service may host a variety of business-critical information, ranging from users and passwords to other identity management data. Sometimes important information is accidentally lost, and recovering such information from a massive set of data can be a difficult task. Users would have to search the backup storage system (or other secondary storage system) for deleted or pre-modified files and then attempt to recover them, which can be very time-consuming. The embodiments disclosed herein enable solutions to make any deleted or recently modified data available for predictive recovery.

[0008] The embodiments disclosed herein further include methods for delta anomaly detection for cybersecurity management. The embodiments disclosed herein utilize the intelligent metadata of the backup copy and assist security management services in reducing the scope of anomaly detection scanning. The embodiments disclosed herein may include comparing backup copies of specialized directory service assets at different points in time to determine the changed portions of such assets, generating a differencing file containing (or referencing) the data that differs between the two backup copies, and initiating cybersecurity services on the differencing FBB metadata file. This eliminates the need to reprocess the entire asset if the data does not exhibit changes between backup copies.

[0009] Fig. 1 shows an exemplary system according to one or more embodiments of the invention. The system includes a backup agent (100), one or more clients (120), a production host environment (130), an on-site backup storage system (150), and one or more secondary storage systems (160). The system may include additional, fewer, and / or different components without departing from the invention. Each component may be operably connected to one of the other components via any combination of wired and / or wireless connections. Each component included in Fig. 1 is discussed below.

[0010] In one or more embodiments of the invention, the backup agent (100) manages the backup operations of data in the production host environment (130). The backup operations may include creating, storing, and / or restoring file-based backups (FBBs) stored in the local backup storage system (150) or in one or more secondary storage systems (160). In one or more embodiments of the invention, an FBB is a backup of a file system that is updated, modified, and / or otherwise accessed by the applications (132) in the production host environment (130). The backup agent (100) may perform the method of Fig. 3A, Fig. 4A and Fig. 5A to generate the FBBs and manage memory and access to the FBBs.

[0011] In one or more embodiments of the invention, the backup agent (100) is implemented as a computing device (see, e.g., Fig. 6). The computing device may be, for example, a mobile phone, a tablet computer, a laptop, a desktop computer, a server, a distributed computing system, or a cloud resource. The computing device may include one or more processors, memory (e.g., random access memory), and persistent storage (e.g., hard disk drives, solid-state drives, etc.). The computing device may include instructions stored on the persistent memory that, when executed by the processor(s) of the computing device, cause the computing device to perform the functions of the backup agent (100) described in this application and / or all or a portion of the functions described in the Fig. 3A, Fig. 4A and Fig. 5A.

[0012] In one or more embodiments of the invention, the backup agent (100) is implemented as a logical device. The logical device may utilize the computing resources of any number of computing devices and thereby implement the functionality of the backup agent (100) described in this application and / or all or a portion of the Fig. 3A, Fig. 4A and Fig. 5A.

[0013] While the backup agent (100) in Fig. 1 as a separate unit, the backup agent (100) and any components thereof may be executed as part of the production host environment (130), the backup storage system (150), the clients (120) and / or any other units without departing from the invention.

[0014] In one or more embodiments of the invention, the production host environment (130) hosts applications (132). The applications (132) may be logical entities that execute using computing resources (not shown) of the production host environment (130). Each of the applications may perform similar or different processes. In one or more embodiments of the invention, the applications (132) provide services to users, e.g., clients (not shown). For example, the applications (132) may host components. The components may be, for example, instances of databases, email servers, and / or other components. The applications (132) may also host other types of components without departing from the invention.

[0015] In one or more embodiments of the invention, the applications (132) generate application data used to serve users. The application data may be organized according to a file system. The file system may include any number of files organized into directories. For example, the directories may include paths for accessing the files. The file system may be stored in a container located in the persistent storage (134) of the production host environment (130).

[0016] In one or more embodiments of the invention, the applications (132) are implemented as computer instructions, e.g., computer code, stored on persistent storage (e.g., 134) that, when executed by one or more processors of the production host environment (130), cause the production host environment (130) to provide the functionality of the applications (132) described in that application.

[0017] In one or more embodiments, the production host environment (130) may host a specialized directory service (140) that provides one or more mechanisms for accessing the data by the applications (132). The specialized directory service (140) may provide a data mapping (e.g., a file system) and / or other services for creating, storing, and accessing data stored in the persistent storage (134) of the production host environment (130) and / or from an on-premises backup storage system (150). The specialized directory service (140) may provide user login verification services, directory information storage, user access management services, application programming interfaces (APIs), certificate services, and domain management services.Other services may be provided by the specialized directory service (140) without departing from the invention. An example of a specialized directory service could be Active Directory.

[0018] In one or more embodiments of the invention, the specialized directory service (140) is implemented as computer instructions, e.g., computer code, stored on persistent storage (e.g., 134) that, when executed by one or more processors of the production host environment (130), cause the production host environment (130) to provide the specialized directory service (140) functionality described in this application.

[0019] In one or more embodiments, the persistent storage (134) of the production host environment (130) stores backup policies (142) and restored file data (144). The backup policies (142) may schedule backups of data (e.g., files, file systems, specialized directory service databases, directory information, and / or any other data) created or used by the applications (132). The backup policies (142) may further specify the system (150, 160) in which the FBBs (or portions thereof) are to be stored. For example, a backup policy may specify that sub-assets that include specialized directory service databases be stored in the on-premises backup storage system (150), while sub-assets that do not include a directory service are to be stored in a secondary storage system (160).Further details on such backup policies (142) can be found in . Fig. 3A-3B.

[0020] In one or more embodiments, the restored file data (144) may be data restored from the on-site backup storage system (150), secondary storage systems (160), and / or other storage systems according to restoration procedures initiated by one or more entities of the system. The restoration procedures are described, for example, in the Fig. 4A- 4B discussed.

[0021] In one or more embodiments of the invention, the production host environment (130) further includes an FBB metadata file manager (136). In one or more embodiments of the invention, the FBB metadata file manager (136) obtains FBB metadata files, establishes the relevant metadata attributes, and prepares a virtual FBB file system for the applications (132) to use when accessing the data in the FBBs stored in the backup storage system (150).

[0022] In one or more embodiments of the invention, the production host environment (130) is implemented as a computing device (see, e.g., Fig. 6). The computing device may be, for example, a mobile phone, a tablet computer, a laptop, a desktop computer, a server, a distributed computing system, or a cloud resource. The computing device may include one or more processors, memory (e.g., random access memory), and persistent storage (e.g., hard disk drives, solid-state drives, etc.). The computing device may include instructions stored on the persistent storage that, when executed by the processor(s) of the computing device, cause the computing device to perform the functionality of the production host environment (130) described in this application.

[0023] In one or more embodiments of the invention, the production host environment (130) is implemented as a logical device. The logical device can utilize the computing resources of any number of computing devices, thereby providing the functionality of the production host environment (130) described in this application.

[0024] In one or more embodiments of the invention, the on-site backup storage systems (150) and the secondary storage systems (160) store FBBs. The FBBs may be backup copies for file systems. The file systems may be based on files used by the applications (132). The FBBs may each correspond to a point in time of the file system. The FBBs may be used to restore the file system to a corresponding point in time.

[0025] In one or more embodiments, the tier of data storage may be categorized based on the availability of data in the systems (150, 160). For example, the on-premises backup storage systems (150) may be considered a higher tier than the secondary storage systems (160) based on lower latency in accessing data in the on-premises backup storage system (150) relative to the secondary storage system(s) (160), and the persistent storage (134) is a higher tier than the on-premises backup storage system (150) and the secondary storage system(s) (160).

[0026] In one or more embodiments of the invention, the backup storage system (150) is implemented as a computing device (see, e.g., Fig. 6). The computing device may be, for example, a mobile phone, a tablet computer, a laptop, a desktop computer, a server, a distributed computing system, or a cloud resource. The computing device may include one or more processors, memory (e.g., random access memory), and persistent storage (e.g., hard disk drives, solid-state drives, etc.). The computing device may include instructions stored on the persistent memory that, when executed by the processor(s) of the computing device, cause the computing device to perform the functionality of the backup storage system (150) described in this application.

[0027] In one or more embodiments of the invention, the backup storage system (150) is implemented as a logical device. The logical device can utilize the computing resources of any number of computing devices, thereby providing the functionality of the backup storage system (150) described in this application.

[0028] In one or more embodiments of the invention, each secondary storage system (160) is implemented as a computing device (see, e.g., Fig. 6). The computing device may be, for example, a mobile phone, a tablet computer, a laptop, a desktop computer, a server, a distributed computing system, or a cloud resource. The computing device may include one or more processors, memory (e.g., random access memory), and persistent storage (e.g., hard disk drives, solid-state drives, etc.). The computing device may include instructions stored on the persistent storage that, when executed by the processor(s) of the computing device, cause the computing device to perform the functions of the secondary storage system (160) described in this application.

[0029] In one or more embodiments of the invention, the secondary storage system (160) is implemented as a logical device. The logical device can utilize the computing resources of any number of computing devices, thereby providing the functionality of the secondary storage system (160) described in this application.

[0030] Fig. Figure 2 shows a diagram of a file-based backup without departing from the invention. The file-based backup (200) may be an embodiment of the file-based backup described in Fig. 1. As previously discussed, the file-based backup (200) is a structure containing the data in a file system at a specific point in time. The file-based backup (200) may include file system data (202) and an FBB metadata file (204).

[0031] In one or more embodiments of the invention, the file system data includes data for one or more files (202A, 202B). Each file (202A, 202B) may correspond to a file in the file system. The file data (also referred to as file system data) may further include data tags. In one or more embodiments of the invention, the data tags may be associated with the storage format of the file data (202A, 202B). For example, the file data (202A, 202B) may be stored in a Common Data Streaming Format (CDSF). In one or more embodiments of the invention, the CDSF may be a format that includes the data tags that may correspond to a portion of data and that may specify the FBB corresponding to the portion of data.In this way, the file data (202A, 202B) may include: (i) the data of the files and / or the file system and (ii) the data tags indicating the metadata of one or more sections of the data of the file data (202A, 202B).

[0032] In one or more embodiments of the invention, the FBB metadata file (204) is a data structure that includes metadata corresponding to the files in the file system data (202). The metadata may include attributes (204A, 204N) of a file. Each attribute may describe an aspect of a file. Examples of attributes (204A, 204N) include, but are not limited to: a file identifier, a parent file identifier, a container identifier, a file size, a hash value of the file data, a checksum value of the file data, a header size, an offset of the file where the file is stored, and a directory service associated with the file.

[0033] In one or more embodiments of the invention, the attributes in the FBB metadata file (204) are grouped into attribute regions. The attribute regions may be groupings of metadata attributes. The attribute regions may be grouped based on the probability that an attribute changes between different iterations of an FBB (e.g., 200).

[0034] For example, consider a scenario where a first attribute (e.g., a file size) changes from a first iteration of a file system of a first FBB to a second iteration of the file system of a second FBB. In contrast, a second attribute (e.g., a file name) may remain the same between the two iterations of the file system. In such a scenario, based on the probability of change in future iterations of the system, the first attribute may correspond to a first attribute region and the second attribute to a second attribute region.

[0035] Fig. 3A, Fig. 4A, and Fig. 5A show flow diagrams according to one or more embodiments of the invention. Although the various steps in the flow diagrams are presented and described in order, a person skilled in the art will appreciate that some or all of the steps may be performed in different orders, combined, or omitted, and that some or all of the steps may be performed in parallel. In one embodiment of the invention, the steps described in Fig. 3A, Fig. 4A and Fig. 5A are parallel to all other steps shown in the Fig. 3A, Fig. 4A and Fig. 5A without departing from the scope of the invention.

[0036] Fig. 3A shows a flowchart for managing backup policies of a set of sub-assets according to one or more embodiments of the invention. Fig. 3A can be implemented, for example, by a backup agent (e.g., 100, Fig. 1) are carried out. Other components of the Fig. 1 illustrated system, the procedure of Fig. 3A without departing from the invention.

[0037] In step 300, an FBB creation request is received for one or more assets at a particular time. The FBB request may specify the creation and storage of an FBB of the file system at a particular time. The FBB request may specify the system (e.g., the backup storage system, a secondary storage system, etc.) where the FBB is to be stored. The FBB may specify one or more assets. An asset may be a file, a file system, a directory service database, and / or other data without departing from the invention.

[0038] In step 302, an FBB is generated according to the FBB request. In one or more embodiments of the invention, the FBB is generated by creating a copy of the assets in the backup agent. The FBB may be stored in a backup storage system (e.g., the on-site backup storage system or a secondary backup storage system).

[0039] In step 304, an attribute analysis is performed on an FBB metadata file of the FBB to determine a directory associated with each asset in the FBB. In one or more embodiments, the attribute analysis includes determining the portion of the FBB (e.g., assets or portions of assets of the FBB) associated with a particular directory service. Each asset is analyzed to make such a determination. The attribute analysis may also include determining other attributes of the FBB without departing from the invention.

[0040] In step 306, a set of sub-assets in the FBB is obtained based on the attribute analysis. In one or more embodiments, each sub-asset is a grouping of assets (or portions thereof) assigned to a category. For example, a first category may be assets (or portions of assets) determined to be associated with a specialized directory service. A second category may be assets (or portions thereof) determined not to be associated with the specialized directory service. A third category may be assets (or portions thereof) determined to be associated with a directory service other than the specialized directory service (140, Fig. 1). Each sub-asset can contain data from assets (or sections thereof) from any of the above categories.

[0041] In step 308, backup policies are assigned to each sub-asset in the FBB based on the attribute analysis. According to one or more embodiments, each sub-asset may be assigned a backup policy schedule and a storage location according to the backup policies. For example, a first sub-asset containing data from a specialized directory service may be stored in a local backup storage system according to a backup policy, and a second sub-asset containing data from a non-specialized directory service may be stored in a secondary storage system according to the backup policy. Each backup policy may specify multiple storage locations for a sub-asset without departing from the invention.

[0042] Furthermore, a schedule for future backups of the sub-assets can be assigned based on the backup policies. For example, the first sub-asset in the example above can be backed up more frequently than the second sub-asset.

[0043] In step 310, the sub-assets are stored in the backup storage system(s) based on the backup policies. In one or more embodiments, the backup agent may transfer the sub-assets to their appropriate storage locations (e.g., an on-premises backup storage system, a secondary storage system, etc.).

[0044] To illustrate aspects of the invention, a first example is provided which includes the Fig. 3A is intended to illustrate methods according to one or more embodiments of the invention. Example 1

[0045] The following section describes an example. The example, which is described in Fig. 3B is not intended to limit the invention and is independent of any other example discussed in this application. As an example, consider a scenario where a backup storage system stores a file-based backup (FBB) in a common data streaming format (CDSF).

[0046] Fig. 3B shows a diagram of an example system. The example system includes an on-premises backup storage system (350), a client device (312), a backup agent (320), a cloud storage system (360), and a production host environment (330). For brevity, Fig. 3B does not illustrate all components of the example system. The production host environment includes persistent storage (332) containing specific directory service data (334) associated with a specific directory service.

[0047] The client device (312) sends an FBB creation request to the backup agent (320) for an FBB containing an asset that includes files A, B, and C [1]. The backup agent, in response to the FBB creation request, performs the method of Fig. 3A to analyze the files and retrieve the file data from the persistent storage (332) [2]. Furthermore, the backup agent (320) generates the FBB according to the FBB generation request and stores the FBB in the on-site backup storage system (350) [3]. The backup storage system (350) includes FBB A (352), the FBB A data (354), and an FBB metadata file (356).

[0048] After generating the FBB (352), the backup agent (320) consults the FBB metadata file (356) to perform attribute analysis [4]. Attribute analysis involves determining which of the three files are associated with the specialized directory service. According to the FBB metadata file (356), file A and file C are associated with the specialized directory service, and file B is not associated with any directory service.

[0049] Based on the attribute analysis, the backup agent (320) separates the files into sub-assets. Specifically, files A and C are assigned to a first sub-asset based on their connection to the specialized directory service, and file B is assigned to a second sub-asset. Each sub-asset is assigned a backup policy. Specifically, the first sub-asset is assigned a backup policy that specifies that the sub-asset is stored in the on-premises backup storage system (350) and that future backups are created every 24 hours. The second sub-asset is assigned a backup policy that specifies that the sub-asset is stored in the cloud storage system (360) (e.g., a secondary storage system) and that future backups of the sub-asset are created every 48 hours. Based on the assignment, a backup copy of the second sub-asset is stored in the cloud storage system (360) [5].In this way, the data of file B (364) can be accessed via the cloud storage system (360), while the data of files A and C (354) can be accessed via the on-site backup storage system (350). End of Example 1

[0050] Fig. 4A shows a flowchart for managing proactive asset recovery according to one or more embodiments of the invention. Fig. The method shown in Figure 4A can be executed, for example, by a backup agent (e.g., 100, Fig. 1) are carried out. Other components of the Fig. 1 illustrated system, the procedure of Fig. 4A without departing from the invention.

[0051] In step 400, it is determined whether a backup interval has elapsed. If a backup interval has elapsed, the method proceeds to step 402; otherwise, the method waits a predetermined period of time before returning to step 400.

[0052] In step 402, a new snapshot of the backup is created. In one or more embodiments, the backup is created after a predetermined time interval. The snapshot of the backup may be associated with a point in time. The snapshot of the backup may identify each file in an asset at that point in time. Further, the snapshot of the backup may include a unique identifier based on the most recent modification of each file. For example, the unique identifier may be a hash value of the data associated with the file. As a second example, the unique identifier may be a hash value of a timestamp of the last time the file was opened by an application. The unique identifiers may also be associated with other information without departing from the invention.

[0053] In one or more embodiments, each backup copy may be associated with an FBB. In particular, an FBB may be created using the snapshot of the backup copy and according to any method discussed in this disclosure. For example, the FBB may be created according to Fig. 3A can be generated.

[0054] In step 404, the most recent snapshot of the backup is compared to the previous snapshot of the backup to generate a differential snapshot. In one or more embodiments, the differential snapshot is a data structure that is identical in format to the backup snapshots generated in step 402. The differential snapshot may indicate the files indicated in the previous backup snapshot that are not indicated in the most recent backup snapshot because the file(s) were deleted between the time of the previous backup snapshot (i.e., a first time) and the time of the most recent backup snapshot (i.e., a second time). Further, the differential snapshot may indicate all files that have modifications between the first time and the second time.The modification of such files can be determined by comparing the unique identifiers of each file in the two backup snapshots and including each file with different unique identifiers in the difference snapshot.

[0055] For example, in step 406, it is determined whether the difference snapshot indicates modified or deleted assets (e.g., files). If the difference snapshot indicates modified or deleted assets, the method proceeds to step 408; otherwise, the method returns to step 400.

[0056] In step 408, after determining that a differential snapshot indicates modified or deleted assets, a recovery notification is provided to the application for one or more assets to be recovered based on the differential snapshot. In at least one embodiment, the recovery notification includes at least one or more of the assets in the differential snapshot and a suggestion for recovering any assets indicated in the differential snapshot.

[0057] In step 410, in response to the reclaim notification, a selection for reclaiming one or more assets in an FBB is received. In response to the reclaim notification, the application may respond to select one or more of the assets to be restored. Specifically, the application may indicate that the selected assets should be transferred from their respective location (e.g., the backup storage system or a secondary storage system) to a higher-level storage system. For example, if a selected asset is currently stored in the secondary storage system, the response may indicate that the selected asset should be transferred to the on-site backup storage system for higher-level access.

[0058] In step 412, retrieval of the asset(s) is performed to obtain the assets from a backup storage system and / or any secondary storage system. In one or more embodiments, retrieving each selected asset from its respective location(s) and transferring the selected asset(s) to the parent system (e.g., the production host or the local backup storage system). Retrieving assets may further include reverting a selected asset to the first point in time if the selected asset was modified (and not deleted) from the first point in time to the second point in time. In this way, the selected assets are accessible to the application despite having been modified and / or deleted.

[0059] In one or more embodiments, the reclaiming of assets is performed prior to step 408. By performing the reclaiming prior to sending the reclaim notification, the assets are available before the application is notified of the deleted and / or modified assets, reducing the time between selection and reclaiming.

[0060] To illustrate aspects of the invention, a second example is provided which incorporates the Fig. 4A is intended to illustrate methods according to one or more embodiments of the invention. Example 2

[0061] The following section describes an example. The example, which is described in Fig. 4B is not intended to limit the invention and is independent of any other example discussed in this application. As an example, consider a scenario where a backup storage system stores a file-based backup (FBB) in a common data streaming format (CDSF).

[0062] Fig. 4B shows a diagram of an example system. The example system includes an on-site backup storage system (480), a secondary backup storage system (450), a client device (312), a backup agent (470), and a production host environment (430). For brevity, Fig. 4B does not illustrate all components of the example system. The production host environment includes a metadata file manager (434) and an application (432).

[0063] At a first time, a first snapshot of the backup is created [1]. The first snapshot of the backup (436) contains the files ABC, XYZ, and 123. A corresponding FBB A (452) is created and stored in the secondary backup storage system (452). At a second time, a second snapshot of the backup is created [2]. The second snapshot of the backup (438) contains the files ABC and XYZ. The second snapshot of the backup (438) does not contain the file 123. This indicates that the application (432) deleted the file 123 from the production host environment (430) between the first time and the second time.

[0064] An FBB metadata file manager (434) performs the procedure of Fig. 4A to compare the two backup copies (436, 438) and generate a differential snapshot (not shown) [3]. The differential snapshot indicates file 123. The FBB metadata file manager (434) sends a reclaim message to the application (432) indicating the reclaim of file 123 on the on-premises backup storage system (480) [4]. The application (432) selects the file 123 to be restored. The FBB metadata file manager (434) initiates a reclaim of the file in response to the selection. Specifically, the FBB metadata file manager (434) sends a reclaim request to the backup agent (470) [5]. In response to the recovery, the backup agent (470) receives the file data for the file XYZ from the FBB (460) and stores the file in the on-site backup storage system (480) [6]. End of Example 2

[0065] Fig. 5A shows a flowchart for managing proactive asset recovery according to one or more embodiments of the invention. Fig. The method shown in Figure 5A can be executed, for example, by a backup agent (e.g., 100, Fig. 1) are carried out. Other components of the Fig. 1 illustrated system, the procedure of Fig. 5A without departing from the invention.

[0066] In step 500, an FBB creation request for an asset at a particular point in time is received. The FBB request may specify the creation and storage of an FBB of the file system at a particular point in time. The FBB request may specify the system (e.g., the backup storage system, a secondary storage system, etc.) where the FBB is to be stored. The FBB may specify one or more assets. An asset may be a file, a file system, a directory service database, and / or other data without departing from the invention.

[0067] In step 502, an FBB is generated according to the FBB request. In one or more embodiments of the invention, the FBB is generated by creating a copy of the assets in the backup agent. The FBB may be stored in a backup storage system (e.g., the on-site backup storage system or a secondary backup storage system).

[0068] In step 504, an FBB metadata file corresponding to the FBB is created. In one or more embodiments of the invention, the FBB metadata file is created by generating metadata attributes corresponding to each file in the assets of the FBB. The metadata file may be populated based on the corresponding attributes of the copy of the data associated with the assets (e.g., filename identifiers, file size, etc.). The attributes of the storage location of the FBB metadata file may be generated based on the storage of the FBB in the backup storage system, as performed in step 502.

[0069] In step 506, an anomaly analysis is initiated that uses the FBB metadata file to generate an FBB anomaly report. In one or more embodiments, anomaly analysis is a process of scanning each file in an asset to detect any cybersecurity anomalies and indicating such anomalies in the anomaly report. The anomaly analysis may be initiated by requesting a cybersecurity component of the system to perform the scan and request the anomaly report. The scanning may include detecting whether any encryption has been performed on the file, whether malicious entities (e.g., executable malware) are stored in the file, whether a file's data is corrupted, and / or whether the data is otherwise inaccessible.

[0070] In one or more embodiments, the anomaly analysis is performed using the FBB metadata file by reading the locations specified in the FBB metadata files to locate the data in the FBBs. This allows the cybersecurity component performing the anomaly analysis to recognize the format of the FBB metadata file.

[0071] In one or more embodiments, if the anomaly report indicates corrupted or otherwise inaccessible files, remediation may be performed. Remediation may include restoring any affected files (e.g., corrupted or inaccessible files) from a previous backup, restoring a backup copy of the file, and / or notifying a user of the affected data.

[0072] In step 508, a second FBB associated with the asset is created at a later time. Similar to step 502, the second FBB is created by creating a copy of the assets in the backup agent at the second time. The FBB may be stored in a backup storage system (e.g., the on-site backup storage system or a secondary backup storage system).

[0073] In step 510, a second FBB metadata file is created. Similar to 504, the second FBB metadata file is created by generating metadata attributes corresponding to each file in the assets of the second FBB. The metadata file may be populated based on the corresponding attributes of the copy of the data associated with the assets (e.g., filename identifiers, file size, etc.). The location attributes of the second FBB metadata file may be generated based on the storage of the second FBB in the backup storage system, as performed in step 508.

[0074] In step 512, an asset analysis is performed for the first and second FBBs to obtain a differencing FBB metadata file of the two FBBs. In one or more embodiments, the asset analysis includes comparing the files in the two FBBs to determine any changes between the first two FBBs (e.g., deleted data and / or modified files). The comparison may be performed using the two FBB metadata files. The FBB metadata files may each indicate the files of the corresponding FBBs. The differencing FBB metadata file may indicate the files that were deleted or modified between the first time and the second time. The differencing FBB metadata file may have a similar format to the two FBB metadata files described above.For example, the differencing FBB metadata can specify the storage attributes of the specified files that are deleted and / or modified between the two points in time.

[0075] In step 514, an anomaly analysis is initiated that uses the second FBB's differencing FBB metadata file to generate a second FBB anomaly report. Similar to the anomaly analysis in step 506, the anomaly analysis is a process of scanning each file in an asset, detecting any cybersecurity anomalies, and indicating such anomalies in the anomaly report. The anomaly analysis may include detecting whether encryption has been performed for each file specified in the differencing FBB metadata file, whether malicious entities (e.g., executable malware) are stored in the file, whether a file's data is corrupted, and / or whether the data is otherwise inaccessible.

[0076] By performing the anomaly analysis on the differencing FBB metadata file instead of the second FBB metadata file, the cybersecurity component's resources are reserved for data changes between the two FBBs. This way, data already scanned in the first FBB does not need to be scanned again in the second anomaly analysis of step 514.

[0077] In step 516, remediation is performed based on the anomaly report. In one or more embodiments, remediation may include restoring any affected files (e.g., corrupted or inaccessible files) from a previous backup, regenerating a backup of the file, and / or notifying a user of the affected data.

[0078] To illustrate aspects of the invention, a second example is provided which incorporates the Fig. 5A is intended to illustrate methods according to one or more embodiments of the invention. Example 3

[0079] The following section describes an example. The example, which is described in Fig. 5B is not intended to limit the invention and is independent of any other example discussed in this application. As an example, consider a scenario where a backup storage system is protected by monitoring performed by a cybersecurity component.

[0080] Fig. 5B shows a diagram of an example system. The example system includes a secondary backup storage system (550), a cybersecurity component (570), and a production host environment (530). For brevity, Fig. 4B does not illustrate all components of the example system. The production host environment includes an FBB metadata file manager (534) and an application (432).

[0081] At a first point in time, the first file-based backup (FBB) A is created [1]. FBB A (552) contains the FBB A metadata file (536) and the file data (564). FBB A (552) is stored in the secondary backup storage system (550). FBB A (552) contains data for the files ABC, XYZ, and 123. The cybersecurity component (570) performs an anomaly analysis by scanning the data of the FBB A file (564) and using the FBB A metadata file (536) [2].

[0082] At a second time, FBB B (560) is created [3]. FBB B (560) contains the FBB B metadata file (538) and the file data (566). FBB B (560) is stored in the secondary backup storage system (550). FBB B (560) contains data for the files ABC, XYZ, and 123. Between the first time and the second time, file 123 was modified.

[0083] The FBB Metadata File Manager (534) performs the procedure of Fig. 5A to compare the two FBB metadata files (536, 538) and generate a differencing FBB metadata file (540) [4, 5]. The differencing FBB metadata file (540) specifies file 123 because it is a modified file different from the two FBB metadata files (536, 538). The cybersecurity component (570) uses the differencing FBB metadata file (540) to perform a second anomaly analysis on FBB B (560) by scanning the file data (566) specified in the differencing FBB metadata file (540) [6]. In this way, the cybersecurity component (570) does not waste time or resources rescanning files ABC and XYZ, since they have already been scanned in FBB A (552) and have not been modified between the two backup copies (552, 560). End of Example 3

[0084] As described above, embodiments of the invention may be implemented using computing devices. Fig. 6 shows a schematic representation of a computing device according to one or more embodiments of the invention. The computing device (600) may include one or more computer processors (602), non-persistent memory (604) (e.g., volatile memory such as RAM, cache memory), persistent memory (606) (e.g., a hard drive, an optical drive such as a CD drive or a DVD drive, flash memory, etc.), a communications interface (612) (e.g., a Bluetooth interface, an infrared interface, a network interface, an optical interface, etc.), input devices (610), output devices (608), and numerous other elements (not shown) and functions. Each of these components is described below.

[0085] In one embodiment of the invention, the computer processor(s) (602) may be an integrated circuit for processing instructions. The computer processor(s) may, for example, be one or more cores or microcores of a processor. The computing device (600) may also include one or more input devices (610), such as a touchscreen, a keyboard, a mouse, a microphone, a touchpad, an electronic pen, or another type of input device. Furthermore, the communication interface (612) may include an integrated circuit for connecting the computing device (600) to a network (not shown) (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, a mobile network, or another type of network) and / or to another device, such as another computing device.

[0086] In one embodiment of the invention, the computing device (600) may include one or more output devices (608), such as a screen (e.g., a liquid crystal display (LCD), a plasma display, a touchscreen, a cathode ray tube (CRT) monitor, a projector, or other display device), a printer, external memory, or other output device. One or more of the output devices may be the same as or different from the input device(s). The input and output device(s) may be connected locally or remotely to the computer processor(s) (602), the non-persistent memory (604), and the persistent memory (606). There are many different types of computing devices, and the aforementioned input and output device(s) may take other forms.

[0087] One or more embodiments of the invention may be implemented using instructions executed by one or more processors of the data management device. Furthermore, such instructions may correspond to computer-readable instructions stored on one or more non-transitory computer-readable media.

[0088] One or more embodiments of the invention may enhance the operation of one or more computing devices. In particular, embodiments of the invention enhance the operation of storing and accessing data associated with specialized directory services secured and stored in a backup storage system. Embodiments of the invention categorize the data based on the type of directory service (if any) associated with an asset's regions.

[0089] Embodiments of the invention further include proactively providing the ability to quickly restore data deleted or modified by a user in a production host environment. If the data was backed up prior to deletion and / or modification, the embodiments disclosed herein enable quick access to the backed up data and user notification of such access.

[0090] While the invention has been described above with respect to a limited number of embodiments, those skilled in the art, given the benefit of this disclosure, will recognize that other embodiments may be devised that do not depart from the scope disclosed herein. Therefore, the scope of the invention should be limited only by the appended claims.

Claims

[1] A method for managing access to file-based backups (FBBs), the method comprising: Creating, at a first time, a first FBB at a first time, the first FBB comprising a first set of files of an asset at the first time; generating, at a second time after the first time, a second FBB at a second time, the second FBB comprising a second set of files of the asset at the second time; performing an asset analysis on a first FBB metadata file associated with the first FBB and a second FBB metadata file associated with the second FBB to generate a differencing FBB metadata file; Performing an anomaly analysis on the second FBB using the FBB metadata file for differentiation to obtain an anomaly report; and Perform troubleshooting on the second FBB based on the anomaly report. [2] The method of claim 1, wherein the troubleshooting comprises: Identifying a file specified in the differencing FBB metadata file that has been compromised; Retrieve a previous version of the file from the first FBB. [3] The method of claim 1, wherein performing the anomaly analysis comprises: Scanning each file specified in the FBB metadata file to determine a cybersecurity status associated with each file; and Specify the cybersecurity status associated with each file in the anomaly report. [4] The method of claim 1, wherein performing the asset analysis comprises: Comparing a first hash value of a first region in the asset with a second hash value of the first region; Determining that the first hash value and the second hash value do not match; and Specifying the first region in the differentiating FBB metadata file, where the first hash value is assigned to the first FBB and the second hash value is assigned to the second FBB. [5] The method of claim 4, wherein the asset is a specialized directory service database associated with a specialized directory service. [6] The method of claim 5, wherein the first region is a file in the asset. [7] The method of claim 5, wherein the specialized directory service comprises a set of secondary services for accessing files in the asset. [8] The method of claim 1, wherein the first FBB and the second FBB are stored in a backup storage system. [9] A non-transitory computer-readable medium comprising computer-readable program code which, when executed by a computer processor, enables the computer processor to perform a method for managing access to file-based backups (FBBs), the method comprising: Creating, at a first time, a first FBB at a first time, the first FBB comprising a first set of files of an asset at the first time; generating, at a second time after the first time, a second FBB at a second time, the second FBB comprising a second set of files of the asset at the second time; performing an asset analysis on a first FBB metadata file associated with the first FBB and a second FBB metadata file associated with the second FBB to generate a differencing FBB metadata file; Performing an anomaly analysis on the second FBB using the FBB metadata file for differentiation to obtain an anomaly report; and Perform troubleshooting on the second FBB based on the anomaly report, where the problem resolution includes the following: re-creating a backup copy of a file and receiving a newly created file; and Save the newly created file in the second FBB. [10] The non-transitory computer-readable medium of claim 9, wherein performing the anomaly analysis comprises: Scanning each file specified in the FBB metadata file to determine a cybersecurity status associated with each file; and Specify the cybersecurity status associated with each file in the anomaly report. [11] The non-transitory computer-readable medium of claim 9, wherein performing the asset analysis comprises: Comparing a first hash value of a first region in the asset with a second hash value of the first region; Determining that the first hash value and the second hash value do not match; and Specifying the first region in the differentiating FBB metadata file, where the first hash value is assigned to the first FBB and the second hash value is assigned to the second FBB. [12] The non-transitory computer-readable medium of claim 11, wherein the asset is a specialized directory service database associated with a specialized directory service. [13] The non-transitory computer-readable medium of claim 12, wherein the first region is a file in the asset. [14] The non-transitory computer-readable medium of claim 12, wherein the specialized directory service comprises a set of secondary services for accessing files in the asset. [15] The non-transitory computer-readable medium of claim 9, wherein the first FBB and the second FBB are stored in an on-site backup storage system. [16] System comprising: a processor; and Memory that includes instructions that, when executed by the processor, perform a method that includes: Creating, at a first time, a first FBB at a first time, the first FBB comprising a first set of files of an asset at the first time; generating, at a second time after the first time, a second FBB at a second time, the second FBB comprising a second set of files of the asset at the second time; performing an asset analysis on a first FBB metadata file associated with the first FBB and a second FBB metadata file associated with the second FBB to generate a differencing FBB metadata file; Performing an anomaly analysis on the second FBB using the FBB metadata file for differentiation to obtain an anomaly report; and Perform troubleshooting on the second FBB based on the anomaly report, where the problem resolution includes the following: Identifying a file specified in the differencing FBB metadata file that has been compromised; Retrieve a previous version of the file from the first FBB. [17] The system of claim 16, wherein performing the anomaly analysis comprises: Scanning each file specified in the FBB metadata file to determine a cybersecurity status associated with each file; and Specify the cybersecurity status associated with each file in the anomaly report. [18] The system of claim 16, wherein performing the asset analysis comprises: Comparing a first hash value of a first region in the asset with a second hash value of the first region; Determining that the first hash value and the second hash value do not match; and Specifying the first region in the differentiating FBB metadata file, where the first hash value is assigned to the first FBB and the second hash value is assigned to the second FBB. [19] The system of claim 18, wherein the asset is a specialized directory service database associated with a specialized directory service. [20] The system of claim 16, wherein the first FBB and the second FBB are stored in an on-site backup storage system.

Images