USE OF UNCHANGEABLE UNIQUE IDENTIFIERS TO MANAGE DATABASE PROTECTION

Abstract

In general, the technology refers to a method for managing databases. This method involves receiving a database identifier (DID) for a database, generating a unique identifier (UID) for the database using the DID, determining after generation that the database is associated with a data protection policy, and allowing backup operations, specifying the UID, to be performed by an agent operationally connected to the database.

Description

BACKGROUND

[0001] Computing devices may contain any number of internal components, such as processors, memory, and persistent storage. Computing resources associated with (e.g., used by) each of these internal components may be used to generate, store, and back up data. Data backup must be performed in a manner that minimizes the impact on users of the computing devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain embodiments of the technology are described in detail with reference to the accompanying drawings. However, the accompanying drawings only illustrate certain aspects or implementations of the technology by way of example and are not intended to limit the scope of the claims. Fig. 1.1 shows a diagram of a system according to one or more embodiments of the technology. Fig. 1.2 shows a diagram of a configuration of databases according to one or more embodiments of the technology. Fig. Figure 1.3 shows a diagram of the data structure associated with information that can be tracked with each asset according to one or more embodiments of the technology. Fig. 2 shows a flowchart of a method for making discoveries according to one or more embodiments of the technology. Fig. 3.1-3.2 show flow diagrams of a method for protecting assets according to one or more embodiments of the technology. FIG. Fig. 4.1 shows a flowchart of a method for detecting copies according to one or more embodiments of the technology. Fig. 4.2-4.3 show diagrams of databases in accordance with one or more embodiments of the technology. Fig. 5 shows flowcharts of a method for protecting assets according to one or more embodiments of the technology. Fig. 6.1-6.2 show flowcharts for performing the asset record update process according to one or more embodiments of the technology. Fig. 7 shows a computing system according to one or more embodiments of the technology. DETAILED DESCRIPTION

[0003] In general, embodiments of the technology relate to protecting assets (e.g., creating redundant copies of assets) by associating assets with immutable unique identifiers. In the context of this technology, an asset is data or a database associated with a file, folder, and / or other data hierarchy (or structure) (e.g., a volume). Various embodiments relate to identifying assets and then assigning unique identifiers to assets (see, e.g., Fig. 2, Fig. 3.1 and 5) and then managing the protection of these assets using the unique identifiers (see e.g. Fig. 3.2, 4.1, 4.2, 4.3).

[0004] Furthermore, in certain scenarios, the use of the unique identifier can be implemented on a system that has not previously used unique identifiers. Embodiments of the technology address this use case (see, for example, Fig. 3.1 and 5). As explained below, the unique identifiers are generated (or otherwise derived) from the database identifier(s). In certain scenarios, all agents in the system may use the same algorithm (or function) to generate the database identifiers. In other scenarios, specific agents in the system may be updated. In such cases, the data manager (see, for example, Fig. 1.1), which manages the overall protection (also referred to as data protection) of the databases, may contain entries containing database identifiers generated using various algorithms (or functions). Accordingly, the data manager may Fig. 6.1-6.2 to support heterogeneous agents (e.g. agents and legacy agents thereof).

[0005] Regarding unique identifiers, in one embodiment of the technology, a unique identifier is generated for an asset based on certain attributes of the asset. This identifier is unique for each asset and immutable throughout the asset's lifetime, regardless of any changes made to the asset. The asset's protection strategy (also called data protection strategy) is associated with this unique identifier, ensuring that the asset, as well as all copies of the asset (e.g., backups), are protected at all times. This approach takes into account the dynamic nature of the system and its tendency to change over time, ensuring that no asset is unavailable if there is a failure, change, or update to the protection policies of any of the system's assets.

[0006] One or more embodiments of the technology are described below.

[0007] The Fig. 2-6.2 can be used at the locations described in the Fig. 1.1-1.2 and 7 shown systems and / or components.

[0008] Fig. Figure 1.1 shows a diagram of a system according to one or more embodiments described herein. The system includes a data manager (102), one or more hosts (e.g., 200), one or more backup storage systems (e.g., 300), and one or more databases (400). Each of these components is described below.

[0009] In one or more embodiments, the components may be in Fig. 1.1 operatively interconnect via a network (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, a cellular network, etc.). The network may be implemented using any combination of wired and / or wireless connections. Furthermore, the network may comprise various interconnected, network-capable subcomponents (or systems) (e.g., switches, routers, gateways, etc.) that can facilitate communication between the aforementioned system components (100). Furthermore, the components may communicate with each other using any combination of wired and / or wireless communication protocols.

[0010] The data manager (102) may be implemented using one or more computing devices. A computing device may be, for example, mobile phones, tablet computers, laptops, desktop computers, servers, or cloud resources. 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 persistent storage may store computer instructions, e.g., computer code, that, when executed by the processor(s) of the computing device, cause the computing device to perform the functions described herein and / or all or part of the Fig. 2-6.2. The data manager (102) may be implemented using other types of computing devices without departing from the embodiments disclosed herein. Further details regarding computing devices can be found in Fig. 7.

[0011] The data manager (102) may be implemented using logical devices without departing from the embodiments disclosed herein. For example, the data manager (102) may include virtual machines that utilize computing resources of any number of physical computing devices to provide the functionality of the data manager (102). The data manager (102) may be implemented using other types of logical devices without departing from the embodiments disclosed herein.

[0012] In one or more embodiments, the data manager (102) may include functionality to run backup orchestration services databases (400) or may otherwise be programmed to perform this functionality.

[0013] In one or more embodiments, data manager records (104) comprise records (or entries) about the assets (e.g., the databases (400)) that the data manager (102) protects (i.e., performs backup services). The records for each of the assets may include, but are not limited to, (i) one or more identifiers of the assets, (ii) the current role of the asset (e.g., primary, secondary, etc.), and (iii) any other information required by the data manager (102) to perform the methods described herein. Further, the data manager records (104) may include backup policies (or protection policies) that describe which assets should be backed up, when such assets should be backed up, and what type of backup (e.g., incremental or full) should be created.Furthermore, data manager records (104) may be stored in any type of volatile and / or persistent storage using any type of data structure(s). Additional details regarding the information tracked for an asset are described in . Fig. 1.3 and are also described throughout the application.

[0014] In one or more embodiments, the agent management module (106) is a component that enables communication between the data manager (102) and the agent service (202) within the host (200). The agent management module is operatively connected to the agent service (202) within the host (200), which is described in detail below.

[0015] In one or more embodiments, the host (200) may be implemented using one or more computing devices. A 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 persistent storage may store computer instructions, e.g., computer code, that (when executed by the processor(s) of the computing device) causes the computing device to perform the functions of the host (200) described herein and / or all or part of the Fig. 2-6.2. The host (200) may be implemented using other types of computing devices without departing from the embodiments disclosed herein. Further details regarding computing devices can be found in Fig. 7.

[0016] The host (200) may be implemented using logical devices without departing from the embodiments disclosed herein. For example, the host (200) may include virtual machines that utilize computing resources of any number of physical computing devices to provide the functionality of the host (200). The host (200) may be implemented using other types of logical devices without departing from the embodiments disclosed herein.

[0017] In one or more embodiments, the host (200) may include functionality or be otherwise configured to discover assets and perform backup jobs orchestrated by the data manager (102) to copy data in the databases (400) to the backup storage system (300). The host (200) may include functionality to perform all or part of the backup operations described in Fig. 2-6.2. The host (200) may include other and / or additional functionalities without departing from the embodiments disclosed herein.

[0018] In one or more embodiments, the agent service (202) may be a physical or logical component of the host that provides a communication bridge between the data manager (102) and the agent (206) and is further used to locally manage the various agents on the host (200). The agent service (202) is operatively connected to the agent management module (106) (described above), as well as the agent service records (204), and the agent (206).

[0019] In one or more embodiments, the agent service records (204) include records (or entries) about the assets (e.g., the databases (400)) that the agent (206) has discovered. The records for each of the assets may include, but are not limited to, (i) one or more identifiers of the asset, (ii) the current role of the asset (e.g., primary, secondary, etc.), and (iii) any other information required by the agent service (202) to perform the methods described herein. Additional details regarding the information tracked for an asset are described in Fig. 1.3 and are also described throughout the application.

[0020] In one or more embodiments, the agent (206) may be a physical or logical component of the host that provides a communication bridge between the databases (400), the backup storage system (300), and the agent service (202). Furthermore, the agent (206) includes functions for discovering assets and performing backup jobs orchestrated by the data manager (102), with the backup jobs being communicated to the agent (206) via the agent service (202). In one or more embodiments, the host (200) may include multiple agents, each agent configured to interact with a specific type of database (e.g., a database from a specific vendor).

[0021] In one or more embodiments, the agent records (208) include records (or entries) about the assets (e.g., the databases (400)) that the agent (206) has discovered. The records for each of the assets may include, but are not limited to, (i) one or more identifiers of the asset, (ii) the current role of the asset (e.g., primary, secondary, etc.), and (iii) any other information required by the agent (206) to perform the methods described herein. Additional details regarding the information tracked for an asset are described in Fig. 1.3 and are also described throughout the application.

[0022] In one or more embodiments, the backup storage system (300) may be implemented using one or more computing devices. A 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 persistent storage may store computer instructions, e.g., computer code, that, when executed by the processor(s) of the computing device, cause the computing device to perform the functions of the backup storage system (300) described herein and / or all or part of the Fig. 2-6.2. The backup storage system (300) may be implemented using other types of computing devices without departing from the embodiments disclosed herein. Further details regarding computing devices can be found in Fig. 7.

[0023] The backup storage system (300) may be implemented using logical devices without departing from the embodiments disclosed herein. For example, the backup storage system (300) may include virtual machines that utilize computing resources of any number of physical computing devices to provide the functionality of the backup storage system (300). The backup storage system (300) may be implemented using other types of logical devices without departing from the embodiments disclosed herein.

[0024] In one or more embodiments, the backup storage system (300) may include functionality for storing and making data available to users (not shown) of the backup storage system (300) for data protection and / or archiving purposes, or may otherwise be configured to store and make data available to users (not shown). The backup storage system (300) may store backup assets (e.g., databases (400)). The backups may include full backups and / or incremental backups. Other and / or additional data may be stored in the backup storage system (300) without departing from the embodiments disclosed herein. The backup storage system (300) may include other and / or additional functionality without departing from the embodiments disclosed herein.

[0025] In one or more embodiments, the system (100) includes one or more databases (400). In one embodiment, each database may represent a local repository for organizing and consolidating various forms of information. Each database may logically span one or more physical storage devices and / or media (not shown), which may be of the same type or located at the same physical location. Further, information consolidated in each database may be arranged using any storage mechanism (e.g., a file system, a collection of tables or records, etc.). In one embodiment of the invention, each database may be implemented using persistent (i.e., non-volatile) memory.Examples of persistent storage include, but are not limited to, optical storage, magnetic storage, NAND flash memory, NOR flash memory, magnetic random access memory (M-RAM), spin torque magnetic RAM (ST-MRAM), phase change memory (PCM), or other storage media defined as non-volatile storage class memory (SCM). Further details regarding the databases (400) are described in . Fig. 1.2 provided.

[0026] While Fig. 1.1 shows a configuration of components, other system configurations (100) may be used without deviating from the scope of the technology. In addition, while the components in Fig. 1.1 are shown as separate components, one or more of these components may be located on the same physical hardware without departing from the technology.

[0027] Now, with reference to Fig. 1.2, Fig. 1.2 the databases (400) are shown according to one or more embodiments of the technology. The databases are operatively connected to one or more agents (e.g., agent (206)). The databases (400) may be arranged in a high-availability configuration. In such a configuration, each database is assigned a role, e.g., primary, physical standby, logical standby. The databases may be grouped into asset groups, with each asset group comprising at least two databases. Furthermore, each asset group comprises a database with the role "primary" and one or more databases with the role "standby" (which may be a logical standby database or a physical standby database). The role assigned to a particular database may change over time. For example, if a database with the role "primary" becomes unavailable (e.g.,no longer has a network connection), another database in the asset group with the role "Standby" is selected and assigned the role "Primary".

[0028] In one or more embodiments, a database with the role of the primary database (e.g., Database A, 402) is the primary storage location of data for the asset group. Applications (not shown) running on a host (e.g., Fig. 1.1, 200) can read and write data to this database. The databases (400) include functionality for replicating (or otherwise copying) the data from the database with the primary database role to databases with the standby database role (e.g., 404B, 404C, 404D, 404E).

[0029] In one embodiment of the technology, databases with the physical standby role (e.g., 404B, 404C) are identical copies of the database with the primary database role. The contents of the databases with the physical standby role (e.g., 404B, 404C) can initially be created from a backup of the database with the primary database role (e.g., 402). After creation, the databases with the physical standby role (e.g., 404B, 404C) can be kept synchronized with the contents of the database with the primary database role (e.g., 402) by retrieving redo logs from the database with the primary database role (e.g., 402) and then applying the redo logs to the databases with the physical standby role (e.g., 404B, 404C).

[0030] In one embodiment of the technology, databases with the logical standby role (e.g., 404D, 404E) contain the same content as the database with the primary database role (e.g., 402); however, the structure and / or organization of the content may be different. The content of the databases with the logical standby role (e.g., 404D, 404E) may initially be created from a backup of the database with the primary database role (e.g., 402). Once created, the logical standby databases (e.g., 404D, 404E) can be kept synchronized with the contents of the primary database (e.g., 402) by retrieving redo logs from the primary database (e.g., 402), converting the redo logs to SQL statements, and then executing the SQL statements against the contents of the logical standby databases (e.g., 404D, 404E).Unlike databases with the physical standby role, databases with the logical standby role can be used for both data protection and reporting.

[0031] In one or more embodiments, each of the databases (400) may include a local catalog (not shown) that stores information about the backups (or portions thereof) created of the data for each database. In other words, each time a backup of a database is created, the information about the backup (including the location of the backup on the backup storage device) is stored in the local catalog. In various implementations, this information, which is specific to backups for a particular database, is made available (or otherwise accessible) to other components in the system (e.g., the agent service (see, e.g., Fig. 1.1, 202). Furthermore, the information in the local catalog can be used during copy detection processes (see, for example, Fig. 4.1) or other operations that require identification of backups (also called copies) of the database (see, for example, Fig. 5). The information stored in the local catalogs can be organized using any storage mechanism (e.g., a file system, a collection of tables or records, etc.).

[0032] While Fig. 1.2 shows a configuration of components, other database configurations can be used without deviating from the scope of the technology.

[0033] Now, with reference to Fig. 1.3, Fig. 1.3 shows a diagram of information that can be tracked for each asset according to one or more embodiments of the technology.

[0034] As explained above, the system (or components therein) tracks various information about each asset (500). This information may include, but is not limited to, a unique identifier (502), an identifier string (504), and asset attributes (506), each of which is described in detail below.

[0035] The asset attributes (506) correspond to information that the agent (e.g. Fig. 1.1, 206) from the asset. Asset attributes may include various identifiers generated by the specific database software used to operate the database, the size of the database, the type of database, the contents of the database, the database location (e.g., the database path), and / or any other parameter associated with the database. The agent may periodically retrieve asset attributes for databases to which it is operatively connected.

[0036] In scenarios where the asset is a database that is part of a high availability configuration, the database can be assigned a role as a primary, physical, or logical standby database (see, for example, Fig. 1.2). In such scenarios, the asset attributes may include the role currently assigned to the discovered database.

[0037] The agent uses the asset attributes to generate asset identifiers (504A, 504N). Specifically, each asset identifier can be generated (or otherwise derived) from all or part of the asset attributes. For example, the various attributes of the asset can be obtained and then a hash function can be applied to these asset attributes to generate an asset identifier. Each time the asset attributes are updated (or otherwise changed), a new asset identifier is generated. Each asset identifier can be an alphanumeric, numeric, or alphanumeric string.

[0038] According to one embodiment, the agent may include two (or more) identifier functions, each function using a different set of asset attributes to generate an asset identifier. For example, a first function may use three asset attributes and a second function may use five asset attributes. In one embodiment, the five attributes include the three attributes (i.e., the three attributes are a subset of the five attributes). Other combinations of attributes may be used without departing from the technology.

[0039] If multiple asset identifiers are generated with different functions, the functions can be labeled R01, R02, etc., where R01 corresponds to the first function and R02 to the second function. In this example, the function labeled R02 is considered to have a higher rank than the function labeled R01. Furthermore, if multiple asset identifiers are created using different functions, the resulting asset identifiers are labeled with the rank (e.g., R01, R02) of the function used to generate the asset identifiers.

[0040] The identifier chain (504) includes the asset identifiers generated for the asset in a job list (or other data structure), based on when the asset identifier was generated. For example, an asset identifier generated at time 1 may be found after an asset identifier for an asset generated at time 2 in the identifier chain (504), where time 2 is after time 1. The identifier chain (504) is used to track (in an ordered manner) all asset identifiers generated for the lifetime of the asset (or a portion thereof).

[0041] In one embodiment of the technology, the unique identifier (502) or unique ID (UID) may refer to a database identifier that is immutable and does not change over time. The UID may be an alphanumeric, numeric, or alphanumeric string used to identify the asset (e.g., a database). The UID is derived from the highest-ranking asset identifier when the asset is initially discovered. For example, if the asset is discovered and two asset identifiers (tagged R01 and R02, respectively) are generated, the UID is generated by applying a function to the asset identifier tagged R02. In another example, if the asset is discovered and an asset identifier (R01) is generated, the UID is generated by applying a function to the asset identifier tagged R01.

[0042] Asset attributes can change over time. An example of an asset attribute is the asset's role, which can fluctuate between "primary" and "standby." As asset attributes, such as an asset's role, change over time, the asset's database identifier also changes.

[0043] While Fig. 1.3 shows a configuration of components, other data structure configurations may be used without deviating from the scope of the technology. Furthermore, while the description of Fig. 1.3 While identifiers and asset attributes are discussed in the context of databases, the same or substantially the same information can be tracked for other types of assets (e.g., volume) without departing from the technology. Database discovery process

[0044] Fig. 2 shows a flowchart of a method for discovering a database according to one or more embodiments of the technology. Fig. 2 can be performed, for example, by an agent running on a host (e.g., 206). Other components of the system in Fig. 1.1-1.2 can use the procedure of Fig. 2 in whole or in part without departing from the scope of the invention.

[0045] All or part of the process shown may be performed by one or more components of the system. Although the various steps in this flowchart are presented and described in sequence, a person familiar with the relevant technology 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.

[0046] With reference to Fig. 2, the database is identified by the agent in step 200. The agent can use any known or later discovered method to identify the database. The database corresponds to a database (see, for example, 400, Fig. 1.2) that: (i) has been newly added to the system, (ii) was previously unavailable (or offline) and is now available (or online), or (iii) was previously discovered but its role (or other attribute) has changed, requiring (or otherwise triggering) its discovery (or rediscovery).

[0047] As explained above, agents are specific to a particular database type. Therefore, different agents may perform different procedures to discover different database types.

[0048] In step 202, the agent retrieves asset attributes for the database. The agent can use any known or later discovered method to retrieve the asset attributes.

[0049] Continuation of the discussion of Fig. 2. In step 204, the agent generates one or more database identifiers for the database using the asset attributes (or a portion thereof). The database identifiers are generated according to the methods described above.

[0050] In step 206, the agent stores the database identifier(s) generated in step 204 and the asset attributes in the agent records (208).

[0051] In step 208, the database identifier and the asset attributes are transferred to the agent service (e.g. 202 in Fig. 1.1). After receiving the database information, the agent service can save a copy of this information and then transfer this information to the data manager (see, for example, 102 in Fig. 1.1) via the agent management module (106, Fig. 1.1). Further details on the transfer of database identifiers to other components in the system can be found in the Fig. 3.1 and 5.

[0052] The Fig. The procedure shown in Figure 2 can be performed continuously to track changes to the database identifiers of the databases within the system.

[0053] The information obtained in the discovery process is used to Fig. 3.1-6 to start the procedure described.

[0054] While the description in Fig. 2 refers to a database identifier, the database identifier corresponds to an asset identifier if the asset is a database. Fig. However, the method shown in Figure 2 can be used to detect other assets without deviating from the technology. Using immutable unique identifiers to protect assets (e.g. databases)

[0055] Traditionally, a database identifier is used to identify a database. As explained above, because the database identifier is generated using asset attributes, the database identifier can change as the asset's attributes change. Therefore, there is typically no single database identifier associated with a database throughout its lifetime. When assets (e.g., databases) are backed up, the copies of each asset are tagged with the asset's database identifier at the time of the backup process. This is done with the intention of avoiding the discovery of irrelevant copies of an asset tagged with a database identifier. However, this approach can lead to data loss if an asset's database identifier is updated.If an asset's database identifier is updated, any copies of the asset created before the database identifier update may become invalid and no longer be associated with the asset. To track all copies of an asset throughout its lifetime and thus fully protect the data associated with the asset, a database identifier must exist to identify an asset, regardless of updates or changes to the asset's attributes. Unique ID generation

[0056] To adequately manage data, a unique identifier is required for each asset that does not change over time. While the database identifier identifies the current iteration of an asset, a unique identifier is required to identify all versions of an asset throughout their lifetime—even if the asset's attributes change over time. This unique ID is independent of changes and, unlike the database identifier, cannot be lost, as explained above.

[0057] In the Fig. 3.1 and 3.2 show flowcharts of the procedures for the initial recognition and the subsequent generation of a unique ID for the asset. Fig. The procedures described in 3.1-3.2 can be used, for example, by the data manager ( Fig. 1.1, 102), the agent ( Fig. 1.1, 206) and the agent service ( Fig. 1.1, 202). Other components of the system in Fig. 1.1-1.2 can use the procedure of Fig. 3.1-3.2 without departing from the scope of the invention.

[0058] All or part of the process shown may be performed by one or more components of the system. Although the various steps in this flowchart are presented and described in sequence, a person familiar with the relevant technology 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.

[0059] Referring to FIG. 1, as shown in step 3.1, in step 300, a database identifier (referred to as a database ID) is transmitted from the agent to the agent service. This database identifier may be the database identifier of the asset, which is generated using asset attributes of the asset, as described above (see, e.g., Fig. 1.3). Furthermore, in various embodiments, if the agent generates multiple database identifiers (each with a different rank), step 300 may include sending multiple database identifiers to the agent service.

[0060] Further, in certain embodiments, the agent may transmit the current database identifier(s) (i.e., the database identifier(s) most recently generated by the agent) and the most recent previous database identifier(s) (i.e., the database identifier(s) immediately prior to the one most recently generated by the agent).

[0061] In step 302, the agent receives the database identifier for the asset from the agent service. The agent service then stores the current database identifier for the asset. The process then continues with step 304.

[0062] However, in one embodiment, if the agent service receives the current database identifier(s) and the most recent previous database identifier(s), the agent service may use the most recent previous database identifier(s) to determine whether an existing agent service record exists that specifies the current previous database identifier(s). More specifically, the agent service may query the identifier chains of the agent service records associated with the previously discovered assets to determine whether an agent service record exists that contains the most recent previous database identifier(s).

[0063] If such an agent service record exists, (i) it is determined that the asset has been previously discovered, (ii) the identifier string associated with the asset is updated to include the current database identifier(s), and (iii) the method ends. However, if there is no match, then the asset has not been previously discovered and the process continues to step 304.

[0064] In step 304, a unique identifier for the asset is generated by the agent service using the database identifier. If there are multiple database identifiers received by the agent, the unique ID is generated from the highest-ranking database identifier of the asset received in step 302. This unique ID is immutable and does not change over time, nor does the asset's database identifier. The unique ID is stored by the agent service and marked as NEW. The NEW tag indicates that the asset associated with the unique identifier is not currently protected (i.e., associated with a privacy policy).

[0065] In step 306, the unique ID for the asset is transferred from the agent service to the data manager.

[0066] In step 308, it is determined whether the unique ID that the data manager receives from the agent service already exists in the system or not. The method proceeds to step 310. If the unique ID for the asset does not already exist, the method proceeds to step 312. Step 308 is performed to address scenarios where an asset was previously discovered, but the agent service records on the agent service have been deleted. Thus, while there is a corresponding data manager record indicating the unique ID, the agent service does not have a corresponding agent service record and accordingly treats the asset (i.e., the asset associated with the database ID in step 300) as if it were the first time the agent service has discovered that asset.

[0067] In step 310, the agent service is notified by the data manager that the unique ID for the asset already exists in the system, and the method continues to step 318.

[0068] In step 312, after determining that the unique ID generated for the asset does not yet exist in the system, the unique ID is stored by the data manager (e.g., in the data manager records).

[0069] In step 314, the data manager generates a data protection policy for the database associated with the unique ID. The data protection strategy can, for example, specify the backup frequency and the type of backups to be retained (e.g., full backups or partial backups). The data protection strategy can also specify a retention period for the backups. The data protection strategy can contain additional and / or different information without deviating from the technology.

[0070] In step 316, the agent service is notified by the data manager that the unique ID is now present in the system and associated with a privacy policy.

[0071] In step 318, the tag associated with the unique ID is updated to FINAL. The FINAL tag indicates that the asset associated with the unique ID is now protected by the data manager.

[0072] In step 320, the unique ID is transmitted from the agent service to the agent.

[0073] In step 322, the agent stores the unique ID in agent records. After this step, the process ends.

[0074] While the above description describes storing the unique ID for an asset in Agent, the Agent Service and the Data Manager, each of the components can store additional information (see e.g. Fig. 1.3) and / or store other information about the asset. Furthermore, the above-mentioned components do not necessarily store the same information about the asset; therefore, some components may store more or less information about the asset without deviating from the technology.

[0075] With reference to Fig. 3.2, FIG. 3.2 shows a procedure for processing and validating backup requests by the agent. This procedure is implemented by the agent service ( Fig. 1.1, 202). By default, the system is configured to perform data protection only on assets identified by a unique ID, provided those assets are associated with a data protection policy in the data manager. Enforcement of this policy is performed by the agent service in certain embodiments. Other components can perform this enforcement without deviating from the technology.

[0076] With reference to Fig. 3.2, in step 324, a backup request to back up a specific database is received from the agent. This backup request includes the asset's unique ID.

[0077] In step 326, a determination is made as to whether the unique ID of the asset specified in the backup request has been marked as FINAL or not. Backup operations on this system can only be performed if the associated unique ID has been marked as FINAL, since a FINAL tag indicates that the asset associated with the unique ID is associated with a data protection policy.

[0078] If the unique ID is marked as FINAL, the method continues with step 328. If the associated unique ID has not been marked as FINAL, the method continues with step 330.

[0079] In step 328, the agent service transmits the backup request from step 324 for the asset with the associated unique FINAL ID to the agent. Because backup requests are only permitted for assets with associated unique FINAL IDs, this ensures that each resource being backed up on the system has the protection policy associated with the unique ID. Upon receipt of the backup request by the agent, the agent initiates the backup on the appropriate asset (e.g., database). After the backup is successfully completed, information about the successful backup is passed to the data manager (via an agent service). Initiating the backup process may involve the agent instructing the asset to start a backup operation to copy the data from the asset to the backup storage system.

[0080] In step 330, the backup request for the asset with the associated unique ID not marked as FINAL is blocked. A backup request cannot be submitted if the unique ID is not marked as FINAL, as this means the unique ID has not been verified to match the ID stored in the data manager.

[0081] Although not in Fig. 3.2, other asset operations, such as copy detection, may also be blocked by the agent service until the unique ID is associated with a FINAL tag. Performing copy detection

[0082] Once an asset is associated with a unique ID, all copies of the backup are also linked to the unique ID. More specifically, after an asset has been associated with a unique ID, this information is passed to the corresponding agent (see, for example, step 332). When a subsequent backup request is received from the asset, the agent passes the unique ID to the asset and initiates the backup of the resource. The result of backing up the asset is (i) a backup of the asset stored on the backup storage system and (ii) the addition of one or more entries in a local catalog of the asset, where each entry points to (or otherwise corresponds to) a portion of the backup and is labeled with the unique ID.

[0083] At a later date, the data manager may need to identify all copies (i.e., backups) of the asset. This information can be used by the data manager, for example, to manage the retention policy of the copies (e.g., to determine which copies of the asset should be deleted from the backup storage system).

[0084] Fig. Figure 4.1 shows a flowchart of a procedure for identifying copies of a database using the unique ID. Fig. 4.1 can, for example, be used by the agent ( Fig. 1.1, 206). Other components of the system in Fig. 1.1-1.2 can use the procedure of Fig. 4.1, without departing from the scope of the invention.

[0085] All or part of the process shown may be performed by one or more components of the system. Although the various steps in this flowchart are presented and described in sequence, a person familiar with the relevant technology 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.

[0086] Referring to Fig. 4.1, Fig. .1 shows a method for identifying copies of an asset and assigning the copies to the asset. This methodology is implemented by the agent ( Fig. 1.1, 206).

[0087] With reference to Fig. 4.1, in step 400, the agent receives a copy discovery request for an asset (e.g., a database). The copy discovery request may be received from a data manager (via an agent service) and may include the unique ID.

[0088] In step 402, the agent retrieves the local catalog for the database. Specifically, the agent can extract the unique ID in the copy detection request and then query the agent records to identify an agent record with the unique ID. The agent can then use the contents of the agent record (see, for example, Fig. 1.3) to identify the asset. Once the asset is identified, the agent can send a request to the asset to retrieve the local catalog.

[0089] In step 404, one or more backups (or parts thereof) are identified in the local catalog. Specifically, the entries in the local catalog are analyzed to identify entries tagged with the unique identifier (i.e., the unique identifier specified in the copy detection request). If the local catalog contains other entries that are untagged and / or associated with a different unique ID, these entries are skipped in step 404 because they do not contain the specific unique ID. Information about the identified backups (i.e., the identified entries) is provided to the data manager (via the agent service).

[0090] The data manager can store this information in the appropriate data manager record (for example, the data manager record with the unique ID) and then manage the asset's backups using this information. Example

[0091] With reference to Fig. 4.2 we consider a scenario where a primary database is discovered and linked with a unique ID of A (via the Fig. 3.1). At a later time, a backup database A is created (i.e., Backup A). ​​Backup A comprises three parts (Backup Part 1, Backup Part 2, Backup Part 3). Furthermore, as part of the backup process, three corresponding entries are created in a local catalog for database A (i.e., Local Catalog A), each of the entries being identified by a unique ID A (i.e., Backup Part 1 - UID A, Backup Part 2 - UID A, Backup Part 3 - UID A).

[0092] The data manager then performs a copy detection according to Fig. 4.1 for the asset with unique ID A (i.e., in database A). The result of copy detection is that the data manager identifies the three entries in Local Catalog A and applies retention policy X to these entries, with a retention period of 14 days.

[0093] Referring to Fig. 4.3: After backup A has been created, backup A is used to perform a restore operation to create a development database from database A (i.e., database B (Dev)). As part of the restore operation, local catalog B is created, where local catalog B is a copy of local catalog A. Database B is then discovered and linked to a unique ID of B (via the procedure in Fig. 3.1).

[0094] At a later time, a backup database B is created (i.e., Backup B). Backup B comprises three parts (Backup Part 4, Backup Part 5, Backup Part 6). Furthermore, as part of the backup process, three corresponding entries are created in a local catalog for database A (i.e., Local Catalog B), each of the entries identified by a unique ID B (i.e., Backup Part 4-UID B, Backup Part 5-UID B, Backup Part 6-UID B). At this point, Local Catalog B has six entries.

[0095] The data manager then performs a copy detection according to Fig. 4.1 for the asset with unique ID B (i.e., in database B). The result of copy detection is that the data manager identifies the three entries in local catalog B that are linked to B's unique ID and applies retention policy Y to these entries, with a retention period of five days. While local catalog B has six entries, only three have the unique ID B, and therefore only these entries are identified during copy detection.

[0096] Before implementing the unique IDs and labeling copies with the unique IDs, the scenario under Fig. 4.2 and 4.3, the copy detection performed for local catalog B would result in the incorrect identification of six entries. Therefore, the six entries would be subject to retention policy Y (where backup part 1, backup part 2, and backup part 3 would also be assigned to retention policy X). Consequently, backup part 1, backup part 2, and backup part 3 would be deleted after five days instead of the 14 days expected by the user. This could lead to data unavailability for database A. End of exampleUnique ID assignment for previously protected assets

[0097] Consider a scenario where the system contains assets (e.g., databases) that are already protected by the data manager with a mechanism that does not use unique identifiers. At a later time, the data manager is updated to protect assets with unique identifiers. After the update, the system implements the Fig. 3.1-3.2 on asset discovery and protection However, as explained above, once the data manager has been updated to use unique identifiers, the agent service blocks backup requests and copy discovery requests for assets and copies that do not have a unique identifier. For example, if at time 1, database A has five backups and at time 2, the data manager is updated, copy discovery cannot be performed until it has been associated with a unique identifier (see, for example, 3.1), and during this transition period, copy discovery cannot occur (i.e., it will be blocked, see, for example, Fig. 3.2). Therefore, during the transition period, not all copies of Database A may be recognized (or known) by the Data Manager. This may result in data unavailability if recovery is required during the transition period and not all copies of Database A are known to the Data Manager.

[0098] To solve this problem, Fig. Figure 5 shows a flowchart of a process for assigning a unique ID to an asset that was previously protected. Fig. 5 can be executed, for example, by the data manager (102), the agent (206) and the agent service (202). Other components of the system in Fig. 1.1-1.2 can use the procedure of Fig. 5 without departing from the scope of the invention.

[0099] All or part of the process shown may be performed by one or more components of the system. Although the various steps in this flowchart are presented and described in sequence, a person familiar with the relevant technology 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.

[0100] With reference to Fig. 5. In step 500, the agent transmits a database identifier to the agent service. Step 500 is essentially identical to step 300 in Fig. 3.1.

[0101] In step 502, a determination is made as to whether an existing unique ID exists that corresponds to the database identifier that the agent service receives from the agent. If a corresponding unique ID exists, the method exits. If there is no corresponding unique ID, the method continues to step 504.

[0102] The determination in step 502 includes generating the unique ID (discussed above) from the database identifier and then performing a search of the agent service records to determine if an existing agent service record exists that includes the unique ID.

[0103] Continuing the discussion of FIG. 5, in step 504, a determination is made as to whether there is at least one copy of the database that corresponds to the database identifier that the agent service receives from the agent. If at least one copy of the database exists, the method continues to step 506. However, if no copies exist, the method proceeds to Fig. 3.1. In particular, the unique ID is marked with a NEW tag and the method goes to step 306 in Fig. 3.1.

[0104] With further reference to Fig. 5, with respect to step 504, prior to making the determination, copy discovery was previously performed (i.e., by the data manager prior to the upgrade), and as a result, the agent service records contain information about the copies of the databases identified during this process. Therefore, the determination in step 504 includes using the database identifier to determine whether any copies of the database were previously identified (i.e., whether there was at least one copy of the database).

[0105] Continue with Fig. 5. In step 506, the agent service stores the unique ID for the asset and marks it as DIRTY. In step 508, the unique ID is sent to the data manager. The data manager can then store the unique ID in a data manager record for later use (e.g., if the asset is discovered after the upgrade (see, for example, Fig. 3.1). In step 510, the unique ID is sent to the agent, which then stores the unique ID in an asset record.

[0106] In step 512, copy discovery for the database is initiated by the agent service on the agent. Because the unique ID is marked as DIRTY, copy discovery is performed without using a unique identifier. Therefore, all copies of the database specified in the database's local catalog are identified and considered copies of the database.

[0107] In step 514, the agent notifies the agent service that the copy discovery process performed in step 512 has been completed and that all copies of the database associated with the unique ID marked as DIRTY have been discovered. The information obtained during copy discovery is stored in the agent service records and, if appropriate, made available to the data manager.

[0108] In step 516, the tag associated with the unique ID is updated to FINAL. As described with respect to Fig. 3.2, by setting the flag to FINAL, the Data Manager can issue backup requests and copy discovery requests (as well as other similar requests) to the Agent Service during the transition period, and the Agent Service will allow such requests because the unique ID is marked as a FINAL tag. Updating the database identifier of assets

[0109] Consider a scenario where the system includes agents that use a first function to generate a database identifier. At a later time, some of the agents are updated to use a second function to generate the database identifier. Furthermore, in one embodiment, the first function (also referred to as R01 or the lower-rank function) results in a higher probability of generating the same database identifier for two different databases (i.e., a higher probability of collisions) compared to the second function (also referred to as R021 or the higher-rank function).

[0110] As explained above, the data identifiers are used to generate the unique identifiers and are also used to link assets with unique identifiers (see, for example, data structure in Fig. 1.3). This allows the data manager to support different versions of agents (e.g., a legacy agent and a current agent). Furthermore, the agents and the data manager need a mechanism to determine whether an asset with a given database identifier is a new asset or an existing asset.

[0111] Fig. 6.1-6.2 show flowcharts for performing the asset record update process according to one or more embodiments of the technology. Fig. 6.1-6.2 can be used, for example, by the data manager ( Fig. 1.1, 102). Other components of the system in Fig. 1.1-1.2 can use the procedure of Fig. 6.1-6.2 without departing from the scope of the invention.

[0112] All or part of the process shown may be performed by one or more components of the system. Although the various steps in this flowchart are presented and described in sequence, a person familiar with the relevant technology 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.

[0113] The Fig. 6.1-6.2 allows legacy and current agents to provide database identifiers to data managers (via the agent service), and the data manager can determine whether the database identifiers are associated with new or previously discovered assets.

[0114] With reference to Fig. 6.1, in step 600, an asset notification is received for an asset, the asset notification containing: (i) a database identifier if the asset notification originates from a legacy agent, or (ii) two database identifiers (denoted R01 and R02 (as described above)) if the asset originates from a current agent (i.e., a non-legacy agent).

[0115] In step 602, it is determined whether the asset notification includes multiple database identifiers (DIDs) (i.e., DID R02 and DID R01). If the asset notification includes multiple DIDs, the method continues with step 604. Otherwise, the method continues to Fig. 6.2, step 616 above.

[0116] In step 604, it is determined whether there is a data manager record containing a database identifier generated using the higher-rank function (i.e., DID R02). If there is a data manager record containing a database identifier generated using the higher-rank function, the process exits because the database has already been identified. Otherwise, the process continues to step 606.

[0117] In step 606, a determination is made as to whether there is a data manager record that contains a database identifier generated using the lower-rank function (i.e., DID R01). If there is a data manager record that contains a database identifier generated using the lower-rank function, the process continues to step 610; otherwise, the process continues to step 608.

[0118] In step 608, a new data manager record is created containing the two database identifiers (i.e., DID R02 and DID R01). After that, the process ends.

[0119] In step 610, a determination is made as to whether there is a data manager record containing a database identifier generated using the lower-rank function (i.e., DID R01) and another database identifier generated using the higher-rank function. If such a data manager record exists, the process proceeds to step 612; otherwise, the process continues to step 614.

[0120] In step 612, a new data manager record is created containing the two database identifiers (i.e., DID R02 and DID R01). After that, the process ends. Step 612 considers the scenario where there are two different assets that have the same database identifier generated with the lower-ranked function (i.e., there is a collision of database identifiers generated with R01), but have different database identifiers generated with the higher-ranked function.

[0121] In step 614, the database identifier generated using the higher-rank function is added to an existing record containing only the database identifier generated using the lower-rank function. After this, the process ends. Step 614 considers the scenario where the asset was previously discovered by a legacy agent and has now been discovered by a current (i.e., non-legacy) agent.

[0122] With reference to Fig. 6.2, if the asset notification does not include multiple database identifiers (DIDs), then in step 616, a determination is made as to whether there is a data manager record that includes a database identifier generated using the lower-rank function (i.e., DID R01). If there is a data manager record that includes a database identifier generated using the lower-rank function, the process continues to step 620; otherwise, the process continues to step 618.

[0123] In step 618, a new data manager record is created containing a database identifier (i.e., DID R01). After that, the process ends.

[0124] In step 620, it is determined whether there is a data manager record that contains a database identifier generated using the higher-rank function (i.e., DID R02) and a database identifier generated using the lower-rank function (i.e., DID R02). If such a data manager record exists, the process proceeds to step 624; otherwise, the process ends.

[0125] Step 620 considers the scenario where there are two different assets that have the same database identifier generated using the lower-rank function (i.e., a collision exists), and the data manager contains a data manager record that contains both DID R01 and a database identifier generated using the higher-rank function. In this scenario, the asset that is the subject of the record was previously discovered using a current (i.e., not stale) agent, resulting in the record with two database identifiers.

[0126] In step 622, a new data manager record is created containing a database identifier (i.e., DID R01). After that, the process ends.

[0127] As described above, embodiments of the invention may be implemented using computing devices. Fig.7 shows a diagram of a computing device according to one or more disclosed embodiments. The computing device (700) may include one or more computer processors (702), non-persistent memory (704) (e.g., volatile memory such as RAM, cache memory), persistent storage (706) (e.g., a hard drive, an optical drive such as a CD drive or a DVD drive, flash memory, etc.), a communications interface (712) (e.g., a Bluetooth interface, an infrared interface, a network interface, an optical interface, etc.), input devices (710), output devices (708), and numerous other elements (not shown) and functions. Each of these components is described below.

[0128] In one or more embodiments, the computer processor(s) (702) 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 (700) may also include one or more input devices (710), such as a touchscreen, a keyboard, a mouse, a microphone, a touchpad, an electronic pen, or another type of input device. Furthermore, the communications interface (712) may include an integrated circuit for connecting the computing device (700) 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.

[0129] In one or more embodiments, the computing device (700) may include one or more output devices (708), 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 storage, 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) (702), the non-persistent memory (704), and the persistent memory (706). There are many diverse types of computing devices, and the aforementioned input and output device(s) may take other forms.

[0130] The problems discussed above are intended as examples of problems solved by embodiments described herein, and the scope of the embodiments should not be limited to solving the same / similar problems. The disclosed technology is broadly applicable to solving a range of problems beyond those discussed herein.

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

[0132] The above description includes references to database identifiers. It will be understood by those skilled in the art, who will have the benefit of this detailed description, that a database identifier corresponds to an asset identifier when the asset is a database. While the various embodiments are described with respect to databases, embodiments of the technology may be implemented for other types of assets (e.g., storage volumes) without departing from the technology.

[0133] In the above description, numerous details are set forth as examples of the embodiments described herein. Those skilled in the art, having the benefit of this detailed description, will understand that one or more embodiments of the embodiments described herein may be practiced without these specific details, and that numerous variations or modifications are possible without departing from the scope of the embodiments described herein. Certain details known to those skilled in the art may be omitted in order not to obscure the description.

[0134] In the above description of the figures, each component described with respect to one figure may, in various embodiments described herein, 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 described herein, 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.

[0135] In this application, elements of figures may be labeled B through C or D through E. As used herein, the foregoing labeling means that the element may include any number of elements, and does not require that the element include the same number of elements as any other element labeled B through C or D through E. For example, a data structure may include a first element labeled B and a second element labeled C. This labeling convention means that the data structure may include any number of elements. A second data structure, also labeled A through N, may also include any number of elements. The number of elements of the first data structure and the number of elements of the second data structure may be the same or different.

[0136] Throughout the application, ordinal numbers (e.g., first, second, third, etc.) may be used as an adjective for an element (i.e., any noun in the application). The use of ordinal numbers does not imply or create a particular order of the elements or limit an element to being only a single element, unless expressly disclosed, e.g., through the use of the terms "before," "after," "single," and other such terminology. Rather, the use of ordinal numbers serves to distinguish between the elements. For example, a first element is different from a second element, and the first element may include more than one element and may follow (or precede) the second element in the order of the elements.

[0137] As used herein, the term "operatively connected" or "operative connection" means that there is a direct or indirect connection between elements / components / devices that enables the elements to interact with each other in some way. For example, the term "operatively connected" can refer to any direct (e.g., a direct wired connection between two devices or components) or indirect (e.g., wired and / or wireless connection between any number of devices or components that interconnect the operatively connected devices) connection. Thus, any path by which information can be transmitted can be considered an operative connection.

[0138] While the embodiments described herein have been described with respect to a limited number of embodiments, those skilled in the art and having the benefit of this detailed description will appreciate that other embodiments may be developed that do not depart from the scope of the embodiments disclosed herein. Therefore, the scope of the embodiments should be limited only by the appended claims.

Claims

[1] A method for managing databases, the method comprising: Receiving a database identifier (DID) for a database; Generate a unique identifier (UID) for the database using the DID; Determining, after generation, that the database is associated with a privacy policy; and Allow backup operations to be performed by an agent that is operatively connected to the database, specifying the UID. [2] The method of claim 1, wherein the DID is obtained from the agent. [3] The method of claim 1, wherein determining that the database is associated with the privacy policy comprises: Receiving a notification from a data manager that the database associated with the UID is protected by the data protection policy, where the agent runs on a host that is operatively connected to the database, wherein the data manager is executed on a computing device operatively connected to the host. [4] The method of claim 3, wherein generating the UID comprises: Storing the UID with a tag in an agent service record, where a value of the tag is NEW, where after receiving the notification the value of the tag is updated to FINAL. [5] The method of claim 4, wherein the agent service record further comprises the DID. [6] The method of claim 4, further comprising: After updating, send the UID to the agent, where the agent stores the UID and DID in an agent record. [7] The method of claim 1, further comprising: after generating, sending the UID to a data manager; after sending and before determining, receiving a backup request specifying the UID from the data manager, in response to receiving the backup request, determining that the UID is not associated with a data protection policy, in response to determining that the UID is not associated with a data protection policy, blocking the agent from sending the backup request. [8] 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 databases, the method comprising: Receiving a database identifier (DID) for a database; Generate a unique identifier (UID) for the database using the DID; Determining, after generation, that the database is associated with a privacy policy; and Allow backup operations to be performed by an agent that is operatively connected to the database, specifying the UID. [9] The non-transitory computer-readable medium of claim 8, wherein the DID is obtained from the agent. [10] The non-transitory computer-readable medium of claim 8, wherein determining that the database is associated with the privacy policy comprises: Receiving a notification from a data manager that the database associated with the UID is protected by the data protection policy, where the agent runs on a host that is operatively connected to the database, wherein the data manager is executed on a computing device operatively connected to the host. [11] The non-transitory computer-readable medium of claim 10, wherein generating the UID comprises: Storing the UID with a tag in an agent service record, where a value of the tag is NEW, where after receiving the notification the value of the tag is updated to FINAL. [12] The non-transitory computer-readable medium of claim 11, wherein the agent service record further comprises the DID. [13] The non-transitory computer-readable medium of claim 11, wherein the method further comprises: After updating, send the UID to the agent, where the agent stores the UID and DID in an agent record. [14] The non-transitory computer-readable medium of claim 8, wherein the method further comprises: after generating, sending the UID to a data manager; after sending and before determining, receiving a backup request specifying the UID from the data manager, in response to receiving the backup request, determining that the UID is not associated with a data protection policy, in response to determining that the UID is not associated with a data protection policy, blocking the agent from sending the backup request. [15] System comprising: an agent running on the system and operatively connected to a database; and an agent service running on the system and configured to: Receiving a database identifier (DID) for the database, wherein the DID is obtained from the agent; Generating a unique identifier (UID) for the database using the DID. After generating, determining that the database is associated with a privacy policy; and Allow backup operations to be processed by the agent, specifying the UID. [16] The system of claim 15, wherein determining that the database is associated with the privacy policy comprises: Receiving a notification from a data manager that the database associated with the UID is protected by the data protection policy, where the agent runs on a host that is operatively connected to the database, wherein the data manager is executed on a computing device operatively connected to the host. [17] The system of claim 16, wherein generating the UID comprises: Storing the UID with a tag in an agent service record, where a value of the tag is NEW, where after receiving the notification the value of the tag is updated to FINAL. [18] The system of claim 17, wherein the agent service record further comprises the DID. [19] The system of claim 17, further comprising: After updating, send the UID to the agent, where the agent stores the UID and DID in an agent record. [20] The system of claim 15, wherein the agent service is further configured to: after generation, sending the UID to a data manager; after sending and before determining, receiving a backup request specifying the UID from the data manager, in response to receiving the backup request, determining that the UID is not associated with a data protection policy, in response to determining that the UID is not associated with a data protection policy, blocking the agent from sending the backup request.

Images