Incremental anomaly detection for dedicated directory service asset backup

Abstract

A method for managing access to a file-based backup (FBB) includes generating a first FBB at a first point in time, wherein the first FBB includes a first set of files of an asset at the first point in time; generating a second FBB at a second time point after the first time point, wherein the second FBB comprises a second group 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 difference FBB metadata file; performing exception analysis on the second FBB by using the difference FBB metadata file to obtain an exception report; and performing a correction on the second FBB based on the exception report.

Description

Background Art

[0001] The computing devices in the system may include any number of internal components, such as processors, memory, and persistent storage. Storing data across multiple computing devices may require extensive use of such internal components. Deduplication of such data prior to storage may improve the overall operation of such computing devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain embodiments of the present invention will now be described with reference to the accompanying drawings. However, the drawings only illustrate certain aspects or implementations of the present invention by way of example and are not intended to limit the scope of the claims.

[0003] Figure 1 A diagram of a system according to one or more embodiments of the invention is shown.

[0004] Figure 2 A diagram illustrating file-based backup (FBB) in accordance with one or more embodiments of the invention.

[0005] Figure 3A A flow chart of a backup strategy for managing a set of sub-assets according to one or more embodiments of the present invention is shown.

[0006] Figure 3B A first example according to one or more embodiments of the present invention is shown.

[0007] Figure 4A A flow chart for managing active asset recovery according to one or more embodiments of the present invention is shown.

[0008] Figure 4B A second example according to one or more embodiments of the present invention is shown.

[0009] Figure 5A A flow chart for performing incremental anomaly detection to implement security protection according to one or more embodiments of the present invention is shown.

[0010] Figure 5B Examples of one or more embodiments according to the invention are shown.

[0011] Figure 6 A diagram showing a computing device in accordance with one or more embodiments of the invention. DETAILED DESCRIPTION

[0012] Specific embodiments will now be described with reference to the accompanying drawings. In the following description, numerous details are set forth as examples of the present invention. It will be appreciated 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 changes or modifications may also be possible without departing from the scope of the present invention. In order to avoid obscuring the description, certain details known to those of ordinary skill in the art have been omitted.

[0013] In the following description of the drawings, any component described with respect to the drawings may be equivalent to one or more similarly named components described with respect to any other drawings in various embodiments of the present invention. For the sake of brevity, the description of these components will not be repeated with respect to each figure. Therefore, each embodiment of the components of each drawing is incorporated by reference and is assumed to be optionally present in each other drawing with one or more similarly named components. Additionally, according to various embodiments of the present invention, any description of the components of a certain figure should be interpreted as an optional embodiment, which can be implemented in addition to, in conjunction with, or in place of the embodiment described with respect to the corresponding similarly named components in any other drawings.

[0014] In general, embodiments of the present invention relate to methods and systems for managing file-based backups. Embodiments of the present invention relate to a system for utilizing a file-based backup (FBB) metadata file stored in a backup storage system to enable access to the data of the FBB by an application that manages a file system corresponding to the FBB. The application can be operated from a production host environment that is operatively connected to the backup storage system. The FBB metadata file can be utilized by obtaining attributes corresponding to the data in the FBB (including storage location, file name, and file size) and allowing the application to access these attributes. The FBB metadata file manager executed on the production host environment can utilize the obtained attributes to enable the application to access the data (e.g., files) in the FBB. For example, the FBB metadata file manager can implement a virtual file system that specifies files in a file-based backup and storage locations in a backup storage system.

[0015] Embodiments disclosed herein discuss use cases for using different retention and / or post-backup tiering for different data segments of a large asset that is backed up as a composite data asset. Embodiments disclosed herein include reducing the complexity of managing multiple schedules, policies, and distributions before and during backup generation. After the backup is complete, sub-data assets are dynamically created based on the attributes of the asset (e.g., whether the asset is associated with a dedicated directory service). Each of the sub-assets may have a different retention. For example, an entire file system may be protected as a single asset, but after the backup, the dedicated directory service and non-dedicated directory service data may be intelligently split and sub-data assets created. Further based on the importance of the data and user preferences, these sub-assets may be associated with different retention and tiering policies.

[0016] Embodiments disclosed herein also include methods and systems for implementing predictive recovery of assets associated with a dedicated directory service. A dedicated directory service can host a wide range of mission-critical information, starting with users and passwords and other identity management data. Sometimes, critical information is lost inadvertently, and recovering such information from a large amount of data can be a daunting task. Before modifying from a previous backup in a backup storage system (or any other secondary storage system), a user must search for the deleted file or files and then attempt to restore, which can be very time consuming. Embodiments disclosed herein implement a solution that makes any deleted or recently modified data ready for predictive recovery.

[0017] Embodiments disclosed herein also include methods for incremental anomaly detection for network security management. Embodiments disclosed herein utilize intelligent backup metadata and help security management services narrow the scope of scans for anomaly detection. Embodiments disclosed herein may include: comparing backup snapshots of dedicated directory service assets at different points in time to determine the changed parts of such assets; generating a differential file that includes (or references) different data between two backup snapshots; and initiating network security services on the differential FBB metadata file. In this way, if the data has not changed between backups, the entire asset does not have to be reprocessed.

[0018] Figure 1 An example system according to one or more embodiments of the present invention is shown. The system includes a backup agent (100), one or more clients (120), a production host environment (130), an on-premise backup storage system (150), and one or more auxiliary storage systems (160). The system may include additional, fewer, and / or different components without departing from the present invention. Each component may be operably connected to any other component via any combination of wired and / or wireless connections. The following discusses Figure 1Each component shown.

[0019] In one or more embodiments of the invention, a backup agent (100) manages backup operations for data in a production host environment (130). The backup operations may include generating, storing, and / or restoring a file-based backup (FBB) stored in an on-premises backup storage system (150) or an auxiliary storage system (160). In one or more embodiments of the invention, an FBB is a backup of a file system that has been updated, modified, and / or otherwise accessed by an application (132) in the production host environment (130). The backup agent (100) may execute Figure 3A , Figure 4A and Figure 5A Methods are used to generate FBBs and manage storage and access to FBBs.

[0020] In one or more embodiments of the present invention, the backup agent (100) is implemented as a computing device (see, e.g. Figure 6 The computing device may be, for example, a mobile phone, a tablet computer, a laptop computer, a desktop computer, a server, a distributed computing system, or a cloud resource. The computing device may include one or more processors, a memory (e.g., a random access memory), and a permanent storage device (e.g., a disk drive, a solid-state drive, etc.). The computing device may include instructions stored on the permanent storage device that, when executed by a processor of the computing device, cause the computing device to perform the functions of the backup agent (100) described throughout the present application and / or Figure 3A , Figure 4A and Figure 5A All or part of the method shown.

[0021] In one or more embodiments of the present invention, the backup agent (100) is implemented as a logical device. The logical device can utilize the computing resources of any number of computing devices and thereby provide the functionality and / or the backup agent (100) described throughout this application. Figure 3A , Figure 4A and Figure 5A All or part of the method shown.

[0022] Although the backup agent (100) Figure 1 Although illustrated as separate entities, the backup agent (100) and any of its components may be executed as part of the production host environment (130), the backup storage system (150), the client (120), and / or any other entity without departing from the present invention.

[0023] In one or more embodiments of the invention, the production host environment (130) hosts applications (132). Applications (132) may be logical entities that are executed 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, applications (132) provide services to users, such as clients (not shown). For example, applications (132) may host components. These components may be instances of, for example, databases, email servers, and / or other components. Applications (132) may host other types of components without departing from the invention.

[0024] In one or more embodiments of the present invention, an application (132) generates application data to be used to serve a user. The application data may be organized according to a file system. A file system may include any number of files organized into directories. For example, a directory may include a path for accessing a file. The file system may be stored in a container stored in a persistent storage device (134) of a production host environment (130).

[0025] In one or more embodiments of the present invention, the application (132) is implemented as computer instructions (e.g., computer code) stored on a persistent storage device (e.g., 134) that, when executed by a processor of the production host environment (130), cause the production host environment (130) to provide the functionality of the application (132) described throughout the present application.

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

[0027] In one or more embodiments of the present invention, the dedicated directory service (140) is implemented as computer instructions (e.g., computer code) stored on a persistent storage device (e.g., 134), which, when executed by a processor of the production host environment (130), causes the production host environment (130) to provide the functionality of the dedicated directory service (140) described throughout this application.

[0028] In one or more embodiments, a persistent storage device (134) of a production host environment (130) stores a backup policy (142) and restored file data (144). The backup policy (142) may specify a schedule for backing up data (e.g., files, file systems, dedicated directory service databases, directory information, and / or any other data) generated or used by the application (132). The backup policy (142) may also specify the storage system (150, 160) in which the FBB (or portions thereof) will be stored. For example, the backup policy may specify that sub-assets including a dedicated directory service database will be stored in an on-premises backup storage system (150), and sub-assets not associated with the directory service will be stored in an auxiliary storage system (160). Additional details of such a backup policy (142) may be found at FIG. 3A to FIG. 3B is discussed in.

[0029] In one or more embodiments, the restored file data (144) may be data that has been restored from an on-premises backup storage system (150), an auxiliary storage system (160), and / or other storage systems according to a restore procedure initiated by one or more entities in the system. FIG. 4A to FIG. 4B The recovery procedure is discussed in.

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

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

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

[0033] In one or more embodiments of the present invention, the on-premises backup storage system (150) and the auxiliary storage system (160) store FBBs. The FBBs may be backups of a file system. The file system may be based on files used by the application (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 such corresponding points in time.

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

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

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

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

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

[0039] Figure 2 A diagram showing a file-based backup without departing from the present invention. The file-based backup (200) may be Figure 1 . As described above, the file-based backup (200) is a data structure that includes data in a file system at a certain point in time. The file-based backup (200) may include file system data (202) and FBB metadata files (204).

[0040] In one or more embodiments of the present invention, the file system data includes data (202A, 202B) of one or more files. Each file data (202A, 202B) may correspond to a file in the file system. The file data (also referred to as file system data) may also include a data tag. In one or more embodiments of the present invention, the data tag 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 stream format (CDSF). In one or more embodiments of the present invention, the CDSF may be a format including a data tag, which may correspond to a portion of the data and may specify an FBB corresponding to the data portion. In this way, the file data (202A, 202B) may include: (i) data of a file and / or file system, and (ii) a data tag specifying metadata of one or more data portions of the file data (202A, 202B).

[0041] In one or more embodiments of the present invention, the FBB metadata file (204) is a data structure that includes metadata corresponding to a file in the file system data (202). The metadata may include attributes (204A, 204N) of the file. Each attribute may describe an aspect of the 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.

[0042] In one or more embodiments of the invention, the attributes in the FBB metadata file (204) are grouped into attribute zones. Attribute zones can be groupings of metadata attributes. Attribute zones can be grouped based on the likelihood that the attributes will change between various iterations of the FBB (e.g., 200).

[0043] For example, consider a scenario where a first attribute (e.g., file size) changes from a first iteration of a file system of a first FBB to a second iteration of a file system of a second FBB. In contrast, a second attribute (e.g., file name) may remain unchanged between two iterations of the file system. In this case, based on the likelihood that they will change in future iterations of the file system, the first attribute may correspond to a first attribute area, and the second attribute may correspond to a second attribute area.

[0044] Figure 3A , Figure 4A and Figure 5AFlowcharts according to one or more embodiments of the present invention are shown. Although the various steps in the flowchart are presented and described sequentially, it should be understood by those skilled in the relevant art that some or all of the steps may be performed in a different order, may be combined or omitted, and some or all of the steps may be performed in parallel. In one embodiment of the present invention, without departing from the scope of the present invention, Figure 3A , Figure 4A and Figure 5A The steps shown in Figure 3A , Figure 4A and Figure 5A Any other steps shown in .

[0045] Figure 3A A flow chart of a backup strategy for managing a set of sub-assets according to one or more embodiments of the present invention is shown. Figure 3A The method shown in can be implemented by, for example, a backup agent (e.g., 100, Figure 1 Without departing from the present invention, Figure 1 Other components of the system shown in FIG. Figure 3A The method in .

[0046] In step 300, a FBB generation request is obtained for one or more assets at a certain point in time. The FBB request may specify a FBB for generating and storing a file system at the time point. The FBB request may specify a storage system (e.g., a backup storage system, an auxiliary storage system, etc.) in which the FBB will be stored. The FBB may specify one or more assets. Without departing from the present invention, an asset may be a file, a file system, a directory service database, and / or other data.

[0047] In step 302, an FBB corresponding to the FBB request is generated. In one or more embodiments of the present invention, the FBB is generated by generating a copy of the asset in the backup agent. The FBB can be stored in a backup storage system (e.g., an on-premises backup storage system or an auxiliary backup storage system).

[0048] In step 304, attribute analysis is performed on the FBB metadata file of the FBB to determine the catalog associated with each asset in the FBB. In one or more embodiments, the attribute analysis includes determining that a portion of the FBB (e.g., an asset or a portion of an asset of the FBB) is associated with a dedicated catalog service. Each asset is analyzed to make such a determination. Without departing from the present invention, the attribute analysis may include determining other attributes of the FBB.

[0049] 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 set of assets (or portions thereof) associated with a certain category. For example, a first category may be assets (or portions thereof) determined to be associated with a dedicated directory service. A second category may be assets (or portions thereof) determined not to be associated with a dedicated directory service. A third category may be assets (or portions thereof) determined not to be associated with a dedicated directory service discussed throughout this disclosure (140, Figure 1 )'s directory service. Each sub-asset may include data for an asset (or portion thereof) of one of the aforementioned categories.

[0050] In step 308, a backup policy is assigned to each sub-asset in the FBB based on the attribute analysis. In one or more embodiments, a schedule for the backup policy and a storage location according to the backup policy may be assigned to each sub-asset. For example, a first sub-asset including data for a dedicated directory service may be stored in an on-premises backup storage system according to the backup policy, and a second sub-asset including data for a non-dedicated directory service may be stored in an auxiliary storage system according to the backup policy. Without departing from the present invention, each backup policy may specify multiple storage locations for a sub-asset.

[0051] In addition, a future backup schedule for a sub-asset may be assigned based on a backup policy. For example, the first sub-asset in the above example may be backed up more frequently than the second sub-asset.

[0052] In step 310, the sub-asset is stored in a backup storage system based on the backup policy. In one or more embodiments, the backup agent can transfer the sub-asset to its corresponding storage location (eg, an on-premises backup storage system, an auxiliary storage system, etc.).

[0053] In order to clarify various aspects of the present invention, a first example is provided. Figure 3A The method according to one or more embodiments of the present invention is discussed in.

[0054] Example 1

[0055] The following sections describe the examples. Figure 3B The examples shown in are not intended to limit the invention and are independent of any other examples discussed in this application. Turning to the examples, consider a scenario where a backup storage system stores file-based backups (FBBs) in a common data stream format (CDSF).

[0056] Figure 3BA diagram of an example system is shown. 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 the sake of brevity, not all components of the example system are shown in Figure 3B The production host environment includes a persistent storage device (332) including dedicated directory service data (334) associated with the dedicated directory service.

[0057] The client device (312) sends a FBB generation request to the backup agent (320) for an FBB, wherein the FBB includes assets including files A, B, and C [1]. In response to the FBB generation request, the backup agent executes Figure 3A The method is used to analyze the file, thereby obtaining the data of the file from the persistent storage device (332) [2]. In addition, the backup agent (320) generates an FBB according to the FBB generation request, and stores the FBB in the on-premises backup storage system (350) [3]. The on-premises backup storage system (350) includes an FBB A (352), which includes FBBA data (354) and an FBB metadata file (356).

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

[0059] Based on the attribute analysis, the backup agent (320) separates the files into sub-assets. Specifically, files A and C are associated with a first sub-asset based on their association with a dedicated directory service, and file B is associated with a second sub-asset. A backup policy is assigned to each sub-asset. Specifically, a backup policy is assigned to the first sub-asset, the backup policy specifying that the sub-asset is stored in an on-premises backup storage system (350) and future backups are generated every 24 hours. A backup policy is assigned to the second sub-asset, the backup policy specifying that the sub-asset is stored in a cloud storage system (360) (e.g., an auxiliary storage system) and future backups of the sub-asset are generated every 48 hours. Based on the assignment, a backup of the second sub-asset is stored in the cloud storage system (360) [5]. In this way, file B data (364) can be accessed from the cloud storage system (360), and file A and C data (354) can be accessed from the on-premises backup storage system (350).

[0060] Example 1 ends

[0061] Figure 4A A flow chart for managing active asset recovery according to one or more embodiments of the present invention is shown. Figure 4A The method shown in can be implemented by, for example, a backup agent (e.g., 100, Figure 1 Without departing from the present invention, Figure 1 Other components of the system shown in FIG. Figure 4A method.

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

[0063] In step 402, a new backup snapshot is generated. In one or more embodiments, the backup snapshot is generated after a predetermined time interval. The backup snapshot can be associated with a point in time. The backup snapshot can specify each file in the asset at that point in time. In addition, the backup snapshot can include a unique identifier based on the most recent modification to each file. For example, the unique identifier can be a hash value of data associated with the file. As a second example, the unique identifier can be a hash value of a timestamp of when the file was last opened by the application. The unique identifier can be associated with other information without departing from the present invention.

[0064] In one or more embodiments, each backup snapshot can be associated with an FBB. Specifically, the FBB can be generated using the backup snapshots and according to any of the methods discussed throughout this disclosure. For example, the FBB can be generated according to Figure 3A generate.

[0065] In step 404, the most recent backup snapshot is compared to the previous backup snapshot 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 snapshot generated in step 402. Since files have been deleted between the time point of the previous backup snapshot (i.e., the first time point) and the time point of the most recent backup snapshot (i.e., the second time point), the differential snapshot can specify files that were specified in the previous backup snapshot but not specified in the most recent backup snapshot. In addition, the differential snapshot can specify any files that have been modified between the first time point and the second time point. Modifications to such files can be determined by comparing the unique identifiers of each file in the two backup snapshots and including each file with a different unique identifier in the differential snapshot.

[0066] In step 406 , it is determined whether the differential snapshot indicates a modified or deleted asset (eg, file). If the differential snapshot indicates a modified or deleted asset, the method proceeds to step 408 ; otherwise, the method returns to step 400 .

[0067] In step 408, after determining that the differential snapshot indicates modified or deleted assets, a restore notification is provided to the application regarding restoring one or more assets based on the differential snapshot. In one or more embodiments, the restore notification specifies at least one or more of the assets in the differential snapshot and a suggestion to restore any assets specified in the differential snapshot.

[0068] In step 410, in response to the restore notification, a selection is obtained for restoring one or more assets in the FBB. In response to the restore notification, the application may select one or more of the assets to be restored. Specifically, the application may specify that the selected assets are transferred from their corresponding storage locations (e.g., a backup storage system or an auxiliary storage system) to a higher-level storage system. For example, if the selected assets are currently stored in an auxiliary storage system, the response may specify that the selected assets are transferred to an on-premises backup storage system for higher access.

[0069] In step 412, an asset recovery of one or more assets is performed to obtain the assets from the backup storage system and / or any auxiliary storage system. In one or more embodiments, the asset recovery includes obtaining each selected asset from its corresponding storage location and transferring the selected assets to a higher-tier storage system (e.g., a production host or an on-premises backup storage system). The asset recovery may also include: if the selected asset was modified (rather than deleted) from the first point in time to the second point in time, then restoring the selected asset to the first point in time. In this way, the selected asset can still be accessed by the application even though it has been modified and / or deleted.

[0070] In one or more embodiments, asset restoration is performed prior to step 408. By performing asset restoration prior to sending a restore notification, assets are available before the application receives notification of deleted and / or modified assets, thereby reducing the time spent between selection and restoration.

[0071] In order to clarify various aspects of the present invention, a second example is provided, which is intended to illustrate Figure 4A The method according to one or more embodiments of the present invention is discussed in.

[0072] Example 2

[0073] The following sections describe the examples. Figure 4B The examples shown in are not intended to limit the invention and are independent of any other examples discussed in this application. Turning to the examples, consider a scenario where a backup storage system stores file-based backups (FBBs) in a common data stream format (CDSF).

[0074] Figure 4BA diagram of an example system is shown. The example system includes an on-premises backup storage system (480), an auxiliary backup storage system (450), a client device (312), a backup agent (470), and a production host environment (430). For the sake of brevity, not all components of the example system are shown in FIG. Figure 4B The production host environment includes a metadata file manager (434) and an application (432).

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

[0076] FBB Metadata File Manager (434) Execution Figure 4A , to compare two backup snapshots (436, 438) and generate a differential snapshot (not shown) [3]. The differential snapshot specifies file 123. The FBB metadata file manager (434) sends a restore notification to the application (432), the restore notification specifying that file 123 is to be restored to an on-premises backup storage system (480) [4]. The application (432) selects the file 123 requested to be restored. The FBB metadata file manager (434) initiates the restoration of the file in response to the selection. Specifically, the FBB metadata file manager (434) sends a restore request to the backup agent (470) [5]. In response to the restore request, the backup agent (470) obtains the file data of the file XYZ from the FBB (460) and stores the file in the on-premises backup storage system (480) [6].

[0077] Example 2 ends

[0078] Figure 5A A flow chart for managing active asset recovery according to one or more embodiments of the present invention is shown. Figure 5A The method shown in can be implemented by, for example, a backup agent (e.g., 100, Figure 1 Without departing from the present invention, Figure 1 Other components of the system shown in FIG. Figure 5A method.

[0079] In step 500, an FBB generation request is obtained for an asset at a certain point in time. The FBB request may specify a FBB to generate and store a file system at the time point. The FBB request may specify a storage system (e.g., a backup storage system, an auxiliary storage system, etc.) in which the FBB will be stored. The FBB may specify one or more assets. Without departing from the present invention, an asset may be a file, a file system, a directory service database, and / or other data.

[0080] In step 502, an FBB corresponding to the FBB request is generated. In one or more embodiments of the present invention, the FBB is generated by generating a copy of the asset in the backup agent. The FBB can be stored in a backup storage system (e.g., an on-premises backup storage system or an auxiliary backup storage system).

[0081] In step 504, an FBB metadata file corresponding to the FBB is generated. In one or more embodiments of the invention, the FBB metadata file is generated by generating metadata attributes for each file in the asset corresponding to the FBB. The metadata file can be populated based on corresponding attributes of the data copy associated with the asset (e.g., file name identifier, file size, etc.). The storage location attribute of the FBB metadata file can be generated based on the storage of the FBB in the backup storage system, as performed in step 502.

[0082] In step 506, an anomaly analysis is initiated using the FBB metadata file of the FBB to generate an anomaly report for the FBB. In one or more embodiments, an anomaly analysis is the process of scanning each file in the asset to detect any network security anomalies and specifying such anomalies in the anomaly report. An anomaly analysis can be initiated by prompting the network security component of the system to perform a scan and request an anomaly report. The scan can include detecting whether any encryption has been performed on the file, whether any malicious entities (e.g., executable malware) are stored in the file, whether the data of the file is corrupted, and / or whether the data is otherwise inaccessible.

[0083] In one or more embodiments, the data in the FBB is accessed by reading the storage location specified in the FBB metadata file, and the FBB metadata file is used to perform anomaly analysis. In this way, the network security component performing anomaly analysis can recognize the format of the FBB metadata file.

[0084] In one or more embodiments, if the exception report indicates a damaged or otherwise inaccessible file, remediation can be performed. Remediation can include restoring any affected files (e.g., damaged or inaccessible files) from an earlier backup, regenerating backups of files, and / or notifying the user of the affected data.

[0085] In step 508, a second FBB associated with the asset is generated at a later point in time. Similar to step 502, the second FBB is generated by generating a copy of the asset in the backup agent at a second point in time. The FBB may be stored in a backup storage system (e.g., an on-premises backup storage system or an auxiliary backup storage system).

[0086] In step 510, a second FBB metadata file is generated. Similar to step 504, the second FBB metadata file is generated by generating metadata attributes for each file in the asset corresponding to the second FBB. The metadata file can be populated based on corresponding attributes of the data copy associated with the asset (e.g., file name identifier, file size, etc.). The storage location attribute of the second FBB metadata file can be generated based on the storage of the second FBB in the backup storage system, as performed in step 508.

[0087] In step 512, asset analysis is performed on the first FBB and the second FBB to obtain a differential 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 (e.g., deleted data and / or modified files) between the first two FBBs. The comparison can be performed using two FBB metadata files. The FBB metadata files can each specify the files of its corresponding FBB. The differential FBB metadata file can specify files that have been deleted or modified between a first time point and a second time point. The format of the differential FBB metadata file can be similar to the two FBB metadata files discussed above. For example, the differential FBB metadata can specify the storage attributes of a specified file that was deleted and / or modified between two time points.

[0088] In step 514, an anomaly analysis of the second FBB is initiated using the differential FBB metadata file to generate a second anomaly report for the second FBB. Similar to the anomaly analysis of step 506, the anomaly analysis is a process for scanning each file in the asset to detect any network security anomalies and specifying such anomalies in the anomaly report. The anomaly analysis may include detecting whether any encryption is performed on each file specified in the differential FBB metadata file, whether any malicious entities (e.g., executable malware) are stored in the file, whether the data of the file is corrupted, and / or whether the data is otherwise inaccessible.

[0089] By performing anomaly analysis on the difference FBB metadata file (rather than the second FBB metadata file), the resources of the network security component are reserved for data changes between the two FBBs. In this way, there is no need to rescan the data that has been scanned in the first FBB in the second anomaly analysis of step 514.

[0090] In step 516, remediation is performed based on the exception report. In one or more embodiments, remediation can include restoring any affected files (e.g., corrupted or inaccessible files) from a previous backup, regenerating backups of files, and / or notifying users of the affected data.

[0091] In order to clarify various aspects of the present invention, a second example is provided, which is intended to illustrate Figure 5A The method according to one or more embodiments of the present invention is discussed in.

[0092] Example 3

[0093] The following sections describe the examples. Figure 5B The examples shown in are not intended to limit the invention and are independent of any other examples discussed in this application. Turning to the examples, consider a scenario where a backup storage system is protected by monitoring performed by a network security component.

[0094] Figure 5B A diagram of an example system is shown. The example system includes a secondary backup storage system (550), a network security component (570), and a production host environment (530). For the sake of brevity, not all components of the example system are shown in Figure 4B The production host environment includes the FBB metadata file manager (534) and the application (432).

[0095] At a first point in time, a first file-based backup (FBB) A is generated [1]. FBB A (552) includes FBB A metadata file (536) and file data (564). FBB A (552) is stored in the secondary backup storage system (550). FBB A (552) includes data of files ABC, XYZ, and 123. The network security component (570) performs anomaly analysis by scanning the FBBA file data (564) using the FBB A metadata file (536) [2].

[0096] At the second time point, FBB B (560) is generated [3]. FBB B (560) includes FBB B metadata file (538) and file data (566). FBB B (560) is stored in the secondary backup storage system (550). FBB B (560) includes data of files ABC, XYZ, and 123. Between the first time point and the second time point, file 123 is modified.

[0097] FBB Metadata File Manager (534) Execution Figure 5AThe method of comparing two FBB metadata files (536, 538) and generating a differential FBB metadata file (540) [4, 5]. The differential FBB metadata file (540) specifies file 123 because this is the modified file that is different between the two FBB metadata files (536, 538). The network security component (570) uses the differential FBB metadata file (540) to perform a second anomaly analysis on FBB B (560) by scanning the file data (566) specified in the differential FBB metadata file (540) [6]. In this way, the network security component (570) does not waste time or resources rescanning files ABC and XYZ because they have already been scanned in FBB A (552) and have not changed between the two backups (552, 560).

[0098] Example 3 ends

[0099] As described above, embodiments of the present invention may be implemented using a computing device. Figure 6 A diagram of a computing device according to one or more embodiments of the present invention is shown. The computing device (600) may include one or more computer processors (602), non-persistent storage devices (604) (e.g., volatile memory, such as random access memory (RAM), cache memory), persistent storage devices (606) (e.g., hard disk, optical drive (such as compact disk (CD) drive or digital versatile disk (DVD) drive), flash memory, etc.), communication interface (612) (e.g., Bluetooth interface, infrared interface, network interface, optical interface, etc.), input device (610), output device (608) and many other elements (not shown) and functions. Each of these components is described below.

[0100] In one embodiment of the present invention, the computer processor (602) may be an integrated circuit for processing instructions. For example, the computer processor may 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 touch screen, a keyboard, a mouse, a microphone, a touch pad, an electronic pen, or any other type of input device. In addition, 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 any other type of network) and / or another device (such as another computing device).

[0101] 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 touch screen, a cathode ray tube (CRT) monitor, a projector, or other display device), a printer, an external storage device, or any other output device. One or more of the output devices may be the same as or different from the input device. The input and output devices may be connected locally or remotely to the computer processor (602), the non-persistent storage device (604), and the persistent storage device (606). There are many different types of computing devices, and the previously mentioned input devices and output devices may take other forms.

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

[0103] One or more embodiments of the present invention can improve the operation of one or more computing devices. More specifically, embodiments of the present invention improve the operation of storage and access of data associated with a dedicated directory service backed up and stored in a backup storage system. Embodiments of the present invention classify data based on the type of directory service associated with a region of an asset, if any.

[0104] Embodiments of the present invention also include the ability to proactively provide rapid recovery of data that may have been deleted or modified by a user in a production host environment. If the data has been backed up before deletion and / or modification, the embodiments disclosed herein can quickly access the backed-up data and notify the user of such access.

[0105] Although the present invention has been described above with respect to a limited number of embodiments, those skilled in the art having benefit of this disclosure will appreciate that other embodiments may be conceived without departing from the scope of the invention as disclosed herein. Accordingly, the scope of the present invention shall be limited solely by the appended claims.

Claims

1. A method for managing access to a file-based backup (FBB), the method comprising: Generate a first FBB at a first time point, wherein the first FBB includes a first set of files of the asset at the first time point; generating a second FBB at a second time point after the first time point, wherein the second FBB includes a second set of files of the asset at the second time point; performing 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 differential FBB metadata file; Performing anomaly analysis on the second FBB using the differential FBB metadata file to obtain an anomaly report; as well as A correction is performed on the second FBB based on the anomaly report.

2. The method of claim 1, wherein the modifying comprises: Identifying a damaged file specified in the differential FBB metadata file; A previous version of the file is retrieved 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 network security status associated with each file; as well as The network security status associated with each file is specified in the exception 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; as well as specifying the first region in the differential FBB metadata file, The first hash value is associated with the first FBB, and the second hash value is associated with the second FBB.

5. The method of claim 4, wherein the asset is a dedicated directory service database associated with a dedicated directory service. The method of claim 5 , wherein the first area is a file in the asset.

7. The method of claim 5, wherein the dedicated directory service includes a set of auxiliary 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 a file-based backup (FBB), the method comprising: Generate a first FBB at a first time point, wherein the first FBB includes a first set of files of the asset at the first time point; generating a second FBB at a second time point after the first time point, wherein the second FBB includes a second set of files of the asset at the second time point; performing 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 differential FBB metadata file; Performing anomaly analysis on the second FBB using the differential FBB metadata file to obtain an anomaly report; as well as Performing correction on the second FBB based on the abnormality report, The amendments include: Regenerate the backup of the file and get the regenerated file; as well as The regenerated file is stored 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 network security status associated with each file; as well as The network security status associated with each file is specified in the exception 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; as well as specifying the first region in the differential FBB metadata file, The first hash value is associated with the first FBB, and the second hash value is associated with the second FBB.

12. The non-transitory computer-readable medium of claim 11, wherein the asset is a dedicated directory service database associated with a dedicated directory service.

13. The non-transitory computer-readable medium of claim 12, wherein the first area 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 auxiliary 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-premises backup storage system.

16. A system comprising: processor; as well as A memory comprising instructions that, when executed by the processor, perform a method comprising: Generate a first FBB at a first time point, wherein the first FBB includes a first set of files of the asset at the first time point; generating a second FBB at a second time point after the first time point, wherein the second FBB includes a second set of files of the asset at the second time point; performing 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 differential FBB metadata file; Performing anomaly analysis on the second FBB using the differential FBB metadata file to obtain an anomaly report; as well as Performing correction on the second FBB based on the abnormality report, The amendments include: Identifying a damaged file specified in the differential FBB metadata file; A previous version of the file is retrieved 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 network security status associated with each file; as well as The network security status associated with each file is specified in the exception 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; as well as specifying the first region in the differential FBB metadata file, The first hash value is associated with the first FBB, and the second hash value is associated with the second FBB.

19. The system of claim 18, wherein the asset is a dedicated directory service database associated with a dedicated directory service.

20. The system of claim 16, wherein the first FBB and the second FBB are stored in an on-premises backup storage system.

Images