Managing database protection with immutable unique identifier

Abstract

In general, the technology relates to a method for managing a database, the method comprising: receiving a database identifier (DID) of the database; generating a unique identifier (UID) of the database using the DID; after the generation, determining that the database is associated with a data protection strategy; and allowing a backup operation specifying the UID to be served by an agent operatively connected to the database.

Description

Background Art

[0001] A computing device may include any number of internal components, such as a processor, 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 needs to be performed in a manner that minimizes the impact on users of the computing device. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0003] Figure 1.1 A diagram illustrating a system in accordance with one or more embodiments of the technology.

[0004] Figure 1.2 A diagram illustrating a configuration of a database in accordance with one or more embodiments of the technology.

[0005] Figure 1.3 A diagram illustrating a data structure associated with information that may be tracked for each asset in accordance with one or more embodiments of the technology.

[0006] Figure 2 A flowchart illustrating a method for performing discovery in accordance with one or more embodiments of the technology.

[0007] Figure 3.1 to Figure 3.2 A flow chart illustrating a method for protecting assets in accordance with one or more embodiments of the technology.

[0008] Figure 4.1 A flow chart illustrating a method for replica discovery in accordance with one or more embodiments of the technology.

[0009] Figure 4.2 to Figure 4.3 A diagram illustrating a database in accordance with one or more embodiments of the technology.

[0010] Figure 5 A flow chart illustrating a method for protecting assets in accordance with one or more embodiments of the technology.

[0011] Figure 6.1 to Figure 6.2 A flow diagram for performing an asset record update operation in accordance with one or more embodiments of the technology is shown.

[0012] Figure 7 A computing system in accordance with one or more embodiments of the technology is shown. DETAILED DESCRIPTION

[0013] In general, embodiments of the present technology are directed to protecting assets (e.g., creating redundant copies of assets) by associating assets with immutable unique identifiers. In the context of the technology, an asset is data or a database associated with a file, folder, and / or any other data hierarchy (or structure) (e.g., a volume). Various embodiments are directed to identifying an asset and then assigning an asset unique identifier (see, e.g., Figure 2 , Figure 3.1 and Figure 5 ) and then use the unique identifiers to manage the protection of these assets (see e.g. Figure 3.2 , Figure 4.1 , Figure 4.2 , Figure 4.3 ).

[0014] Furthermore, in some scenarios, the use of unique identifiers can be implemented on systems that have not previously used unique identifiers. Embodiments of the technology address this use case (see, e.g. Figure 3.1 and Figure 5 As discussed below, the unique identifier is generated from (or otherwise derived from) the database identifier. In some scenarios, all agents in the system may use the same algorithm (or function) to generate the database identifier. In other scenarios, some of the agents in the system may be upgraded. In this case, a data manager (see, e.g., Figure 1.1 ) may include entries including database identifiers generated using different algorithms (or functions). Thus, the data manager may perform Figure 6.1 to Figure 6.2 to support heterogeneous agents (e.g., an agent and its legacy agents).

[0015] With respect to unique identifiers, in one embodiment of the technology, a unique identifier is generated for an asset based on certain attributes of the asset. The identifier is unique to each asset and is immutable throughout the lifecycle of the asset regardless of any changes made to the asset. The asset's protection policy (also known as a data protection policy) will be associated with the unique identifier so that the asset and all copies of the asset (e.g., backups) will always be protected. This approach takes into account the dynamic nature of the system and its tendency to change over time, and ensures that no asset will be unavailable if the protection policy of any asset of the system fails, changes, or is updated.

[0016] One or more implementations of the technology are described below.

[0017] Figure 2 to Figure 6.2 The method described in Figure 1.1 to Figure 1.2 and Figure 7 The invention is performed on the systems and / or components shown in FIG.

[0018] Figure 1.1 A diagram showing 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.

[0019] In one or more embodiments, Figure 1.1 The components of the system (100) may be operatively connected to each other via a network (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, a mobile network, etc.). The network may be implemented using any combination of wired and / or wireless connections. In addition, the network may encompass various interconnected network-enabled subcomponents (or systems) (e.g., switches, routers, gateways, etc.) that may facilitate communication between the above-mentioned system (100) components. In addition, the components may communicate with each other using any combination of wired and / or wireless communication protocols.

[0020] The data manager (102) may be implemented using one or more computing devices. The computing device may be, for example, a mobile phone, a tablet computer, a laptop computer, a desktop computer, a server, or a cloud resource. The computing device may include one or more processors, memory (e.g., random access memory), and persistent storage (e.g., a disk drive, a solid-state drive, etc.). The persistent storage may store computer instructions, such as computer code, that, when executed by a processor of the computing device, cause the computing device to perform the functions described herein and / or in a manner similar to that described herein. Figure 2 to Figure 6.2 All or part of the method shown in . Without departing from the embodiments disclosed herein, the data manager (102) may be implemented using other types of computing devices. For additional details on computing devices, refer to Figure 7 .

[0021] Without departing from the embodiments disclosed herein, the data manager (102) may be implemented using logic devices. For example, the data manager (102) may include a virtual machine that utilizes computing resources of any number of physical computing devices to provide the functionality of the data manager (102). Without departing from the embodiments disclosed herein, the data manager (102) may be implemented using other types of logic devices.

[0022] In one or more embodiments, the data manager (102) may include functionality to perform a backup orchestration services database (400), or may otherwise be programmed to perform a backup orchestration services database (400).

[0023] In one or more embodiments, the data manager records (104) include records (or entries) about assets (e.g., database (400)) that the data manager (102) is protecting (i.e., performing backup services for). The records for each of the assets may include, but are not limited to: (i) one or more identifiers for the asset, (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. In addition, the data manager records (104) may include, but are not limited to, backup policies (or protection policies) that describe which assets to back up, when such assets are backed up, and the type of backup to generate (e.g., incremental or full). In addition, the data manager records (104) may be stored in any type of volatile and / or persistent storage device using any type of data structure. Additional details regarding information tracked for assets are provided in the accompanying drawings. Figure 1.3 and are also described throughout the application.

[0024] 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) in the host (200). The agent management module is operatively connected to the agent service (202) in the host (200), as described in detail below.

[0025] In one or more embodiments, the host (200) can be implemented using one or more computing devices. The computing device can 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 can include one or more processors, a memory (e.g., a random access memory), and a persistent storage device (e.g., a disk drive, a solid-state drive, etc.). The persistent storage device can store computer instructions, such as computer code, which (when executed by a processor of the computing device) causes the computing device to perform the functions of the host (200) described herein and / or to perform operations on the computing device. Figure 2 to Figure 6.2 All or part of the method shown in . Without departing from the embodiments disclosed herein, the host (200) may be implemented using other types of computing devices. For additional details about the computing device, refer to Figure 7 .

[0026] Without departing from the embodiments disclosed herein, the host (200) may be implemented using logic devices. For example, the host (200) may include a virtual machine that utilizes the computing resources of any number of physical computing devices to provide the functionality of the host (200). Without departing from the embodiments disclosed herein, the host (200) may be implemented using other types of logic devices.

[0027] In one or more embodiments, the host (200) may include functionality to discover assets and execute backup jobs orchestrated by the data manager (102), or may be otherwise configured to discover assets and execute backup jobs orchestrated by the data manager (102) to copy data in the database (400) to the backup storage system (300). The host (200) may include functionality to execute Figure 2 to Figure 6.2 The host (200) may include other and / or additional functionality without departing from the embodiments disclosed herein.

[0028] In one or more embodiments, the agent service (202) can 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 also 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 record (204) and the agent (206).

[0029] In one or more embodiments, the agent service record (204) includes records (or entries) about assets (e.g., database (400)) discovered by the agent (206). The record for each of the assets may include, but is not limited to: (i) one or more identifiers for 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 about the information tracked for an asset are provided in Figure 1.3 and are also described throughout the application.

[0030] In one or more embodiments, the agent (206) can be a physical or logical component of the host that provides a communication bridge between the database (400), the backup storage system (300), and the agent service (202). In addition, the agent (206) includes functionality to discover assets and execute backup jobs orchestrated by the data manager (102), where the backup jobs are communicated to the agent (206) via the agent service (202). In one or more embodiments, the host (200) can include multiple agents, where each agent is configured to interact with a specific type of database (e.g., a database from a specific vendor).

[0031] In one or more embodiments, the agent record (208) includes records (or entries) about assets (e.g., database (400)) discovered by the agent (206). The record for each of the assets can include, but is not limited to: (i) one or more identifiers for 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 about the information tracked for an asset are provided in Figure 1.3 and are also described throughout the application.

[0032] In one or more embodiments, the backup storage system (300) can be implemented using one or more computing devices. The computing device can 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 can include one or more processors, a memory (e.g., a random access memory), and a persistent storage device (e.g., a disk drive, a solid-state drive, etc.). The persistent storage device can store computer instructions, such as computer code, which, when executed by a processor of the computing device, causes the computing device to perform the functions of the backup storage system (300) described herein and / or to perform operations on the computing device. Figure 2 to Figure 6.2 All or part of the method shown in . Without departing from the embodiments disclosed herein, the backup storage system (300) may be implemented using other types of computing devices. For additional details about the computing device, refer to Figure 7 .

[0033] Without departing from the embodiments disclosed herein, the backup storage system (300) may be implemented using logical devices. For example, the backup storage system (300) may include a virtual machine that utilizes the computing resources of any number of physical computing devices to provide the functionality of the backup storage system (300). Without departing from the embodiments disclosed herein, the backup storage system (300) may be implemented using other types of logical devices.

[0034] In one or more embodiments, the backup storage system (300) may include functionality or otherwise be configured to store and provide data to a user (not shown) of the backup storage system (300) for data protection and / or archival purposes. The backup storage system (300) may store backup assets (e.g., database (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.

[0035] 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 integrating various forms of information. Each database may logically span one or more physical storage devices and / or media (not shown), which may or may not be of the same type or co-located at the same physical site. In addition, any storage mechanism (e.g., a file system, a collection of tables or records, etc.) may be used to arrange the information integrated in each database. In one embodiment of the present invention, each database may be implemented using a persistent (i.e., non-volatile) storage device. Examples of persistent storage devices include, but are not limited to, optical storage devices, magnetic storage devices, NAND flash memory, NOR flash memory, magnetic random access memory (M-RAM), spin torque magnetic RAM (ST-MRAM), phase change memory (PCM), or any other storage medium defined as non-volatile storage class memory (SCM). Additional details about the database (400) are provided in Figure 1.2 Available in.

[0036] Although Figure 1.1 The configuration of components is shown, but other system (100) configurations may be used without departing from the scope of the technology. Figure 1.1 The components in are shown as distinct components, but without departing from the technology, one or more of these components may be co-located on the same physical hardware.

[0037] Now turn to Figure 1.2 , Figure 1.2 A database (400) is shown according to one or more embodiments of the technology. The database is operatively connected to one or more agents (e.g., agent (206)). The database (400) can be arranged in a high availability configuration. In this configuration, each database is assigned a role, such as primary, physical standby, logical standby. The databases can be grouped into asset groups, where each asset group includes at least two databases. In addition, each asset group includes a database with a primary role and one or more databases with a standby role (which can be logical standby or physical standby). The role associated with a given database may change over time. For example, if a database with a primary role becomes unavailable (e.g., loses network connectivity), another database in the asset group with a standby role is selected and assigned the primary role.

[0038] In one or more embodiments, the database with the primary role (e.g., database A, 402) is the primary storage location for data of the asset group. Figure 1.1, 200) can read data from the database and write data to the database. The database (400) includes functionality to replicate (or otherwise copy) data from a database having a primary role to a database having a standby role (e.g., 404B, 404C, 404D, 404E).

[0039] In one embodiment of the technology, the database (e.g., 404B, 404C) with the physical standby role is an identical copy of the database with the primary role. The content of the database (e.g., 404B, 404C) with the physical standby role can be initially created from a backup of the database (e.g., 402) with the primary role. Once created, the database (e.g., 404B, 404C) with the physical standby role can be synchronized with the content of the database (e.g., 402) with the primary role by obtaining redo logs from the database (e.g., 402) with the primary role and then applying the redo logs to the database (e.g., 404B, 404C) with the physical standby role.

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

[0041] In one or more embodiments, each of the databases (400) may include a local directory (not shown) that stores information about backups (or portions thereof) that consist of the data of each database. In other words, each time a backup of a database is made, information related to the backup (including the location of the backup on the backup storage device) is stored in the local directory. In various implementations, this information specific to the backup of a given database is provided to other components in the system (e.g., a proxy service (see, e.g., Figure 1.1 , 202) (or otherwise accessible to it). In addition, information in the local directory can be found in the replica discovery operation (see, e.g. Figure 4.1) or other operations that require identifying a backup (also called a copy) of a database (see e.g. Figure 5 ) during the process of logging in. Any storage mechanism (such as a file system, a collection of tables or records, etc.) can be used to arrange the information stored in the local directory.

[0042] Although Figure 1.2 A configuration of components is shown, but other database configurations may be used without departing from the scope of the technology.

[0043] Now turn to Figure 1.3 , Figure 1.3 A diagram illustrating information that may be tracked for each asset in accordance with one or more embodiments of the technology.

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

[0045] Asset attributes (506) and agents (e.g. Figure 1.1 , 206) obtain / obtain information corresponding to the asset from the asset. Asset attributes may include, but are not limited to, various identifiers generated by the specific database software used to operate the database, the size of the database, the type of database, the content of the database, the database location (e.g., database path), and / or any other parameters associated with the database. The agent may periodically obtain asset attributes of the database to which it is operatively connected.

[0046] In scenarios where the asset is a database that is part of a high availability configuration, the database can be associated with a primary, physical standby, or logical standby (see e.g. Figure 1.2 ) role. In such a scenario, the asset attributes may include the role currently associated with the discovered database.

[0047] The agent generates asset identifiers (504A, 504N) using the asset attributes. More specifically, each asset identifier can be generated (or otherwise derived) from all or part of the asset attributes. For example, various attributes of the asset can be obtained, and then a hash function can be applied to these asset attributes to generate the asset identifier. Each time an asset attribute is updated (or otherwise changed), a new asset identifier is generated. Each asset identifier can be a string of letters, numbers, or alphanumeric characters.

[0048] In one embodiment, the agent may include two (or more) identifier functions, where each function uses a different set of asset attributes to generate an asset identifier. For example, the first function may use three asset attributes, and the 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 technique.

[0049] In the case where multiple asset identifiers are generated using different functions, the functions may be labeled R01, R02, etc., where R01 corresponds to a first function and R02 corresponds to a second function. In this example, the function labeled with R02 will be considered a higher ranked function relative to the function labeled with R01. Additionally, when multiple asset identifiers are created using different functions, the resulting asset identifiers are labeled with the ranking (e.g., R01, R02) of the function used to generate the asset identifier.

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

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

[0052] Asset attributes may change over time. An example of an attribute of an asset is the role of the asset, which may fluctuate between a primary role and a backup role. Because asset attributes (such as the role of an asset) may change over time, the database identifier of the asset may also change.

[0053] Although Figure 1.3 The configuration of the components is shown, but other data structure configurations may be used without departing from the scope of the technology. Figure 1.3 The description discusses identifiers and asset attributes in the context of a database, but without departing from the technology, the same or substantially the same information can be tracked for other types of assets (e.g., volumes).

[0054] Database discovery process

[0055] Figure 2 A flow diagram illustrating a method for discovering a database in accordance with one or more embodiments of the technology. Figure 2 The method shown may be performed by an agent (e.g., 206) executing, for example, on a host. Without departing from the scope of the present invention, Figure 1.1 to Figure 1.2 Other components of the system can perform Figure 2 all or part of the method.

[0056] All or part of the method shown can be performed by one or more components of the system. Although the various steps in the flow chart are presented and described sequentially, it will be appreciated by those skilled in the art that some or all of the steps can be performed in a different order, can be combined or omitted, and some or all of the steps can be performed in parallel.

[0057] Go to Figure 2 In step 200, the agent identifies the database. The agent may use any known or later discovered method to identify the database. The database corresponds to the following database (see, for example, 400, Figure 1.2 ): (i) newly added to the system, (ii) previously unavailable (or offline) and now available (or online), or (iii) previously discovered but its role (or another attribute) has changed, which requires (or otherwise triggers) its discovery (or rediscovery).

[0058] As mentioned above, agents are specific to a given type of database; therefore, different agents may implement different methods to discover different types of databases.

[0059] In step 202, the agent obtains the asset attributes against the database. The agent may use any known or later discovered method to obtain the asset attributes.

[0060] continue Figure 2 As discussed above, 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 above-described method.

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

[0062] In step 208, the database identifier and asset attributes are sent to a proxy service (eg, Figure 1.1 After receiving the database information, the proxy service can store a copy of the information and then transmit the information via the proxy management module (106, Figure 1.1 ) is transmitted to a data manager (see e.g. Figure 1.1 102 in the system). Additional details regarding the transmission of the database identifier to other components in the system are provided in Figure 3.1 and Figure 5 Described in.

[0063] Figure 2 The method shown in may be performed continuously to track changes to database identifiers of databases within the system.

[0064] The information obtained during the discovery process is used to enable Figure 3.1 to the method described in FIG. 6 .

[0065] Although Figure 2 The description in refers to a database identifier, but when the asset is a database, the database identifier corresponds to the asset identifier. However, without departing from the technical context, Figure 2 The method shown can be used to discover other assets.

[0066] Protect assets (such as databases) using immutable unique identifiers

[0067] Traditionally, database identifiers are used to identify databases. As described above, since database identifiers are generated using asset attributes, the database identifiers undergo changes as the attributes of the asset change. Therefore, there is usually no single database identifier associated with a database throughout the life cycle of the database. When backing up an asset (such as a database), each copy of the asset is marked with the database identifier of the asset at the time of the backup process. The purpose of this is to avoid finding unrelated copies of assets marked with database identifiers; however, this approach may result in data loss when the database identifier of the asset is updated. When the database identifier of the asset is updated, all copies of the asset created before the database identifier is updated may become invalid and no longer associated with the asset. In order to track all copies of the asset throughout the life cycle of the asset, and thereby fully protect the data associated with the asset, there needs to be a database identifier that identifies the asset regardless of any updates or changes made to the asset attributes of the asset.

[0068] Unique ID Generation

[0069] In order to adequately manage the data, a unique identifier for each asset that does not change over time is required. While the database identifier identifies the current iteration of an asset, a unique identifier is required to identify all versions of an asset throughout its lifecycle, even if the properties of the asset change over time. This unique ID is independent of changes and will not be lost, unlike the database identifier discussed above.

[0070] Figure 3.1 to Figure 3.2 A flow chart illustrating a method for initially discovering and then generating a unique ID for an asset. Figure 3.1 to Figure 3.2 The method shown in can be used by, for example, a data manager ( Figure 1.1 , 102), agent ( Figure 1.1 , 206) and proxy services ( Figure 1.1 , 202) is executed. Without departing from the scope of the present invention, Figure 1.1 to Figure 1.2 Other components of the system can perform Figure 3.1 to Figure 3.2 all or part of the method.

[0071] All or part of the method shown can be performed by one or more components of the system. Although the various steps in the flow chart are presented and described sequentially, it will be appreciated by those skilled in the art that some or all of the steps can be performed in a different order, can be combined or omitted, and some or all of the steps can be performed in parallel.

[0072] Go to Figure 3.1 In step 300, a database identifier (referred to as a database ID) is transmitted by the agent to the agent service. The database identifier may be a database identifier of the asset generated using the asset attributes of the asset as described above (see, e.g., Figure 1.3 ). Additionally, in various embodiments, if the proxy generates multiple database identifiers (each with a different ranking), step 300 may include sending the multiple database identifiers to the proxy service.

[0073] Additionally, in some embodiments, the agent may transmit a current database identifier (ie, a database identifier most recently generated by the agent) and a most recent previous database identifier (ie, a database identifier generated immediately before the database identifier most recently generated by the agent).

[0074] In step 302, a database identifier for an asset is received by the proxy service from the proxy. The proxy service then stores the current database identifier for the asset. The process then proceeds to step 304.

[0075] However, in one embodiment, if the proxy service receives a current database identifier and a most recent previous database identifier, the proxy service may use the most recent previous database identifier to determine whether there is an existing proxy service record that specifies the most recent previous database identifier. More specifically, the proxy service may query the identifier chain of proxy service records associated with previously discovered assets to determine whether there are any proxy service records that include the most recent previous database identifier.

[0076] If such a proxy service record exists, then (i) the asset is determined to have been previously discovered, (ii) the identifier chain associated with the asset is updated to include the current database identifier, and (iii) the method ends. However, if there is no match, the asset was not previously discovered and the process proceeds to step 304.

[0077] In step 304, a unique identifier is generated for the asset by the proxy service using the database identifier. If multiple database identifiers are received from the proxy, the unique ID is generated from the highest ranking database identifier of the asset received in step 302. The unique ID is immutable and does not change over time, even if the database identifier of the asset changes. The unique ID is stored by the proxy service and is marked as NEW. The NEW flag indicates that the asset associated with the unique identifier is not currently protected (i.e., not currently associated with a data protection policy).

[0078] In step 306, the unique ID for the asset is transmitted by the proxy service to the data manager.

[0079] In step 308, it is determined whether the unique ID received by the data manager from the proxy service already exists in the system. If the unique ID for the asset already exists, the method proceeds to step 310; if the unique ID for the asset does not yet exist, the method proceeds to step 312. Step 308 is performed to address the following scenario: the asset was previously discovered but the proxy service record on the proxy service was deleted. Thus, although there is a corresponding data manager record for the specified unique ID, the proxy service does not have a corresponding proxy service record and therefore treats the asset (i.e., the asset associated with the database ID in step 300) as the first time the proxy service has discovered the asset.

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

[0081] In step 312, after determining that the unique ID generated for the asset does not already exist in the system, the unique ID is stored by the data manager (eg, in a data manager record).

[0082] In step 314, a data protection policy for the database associated with the unique ID is generated by the data manager. For example, the data protection policy may specify the backup frequency and the type of backup to be obtained (e.g., full backup or partial backup). The data protection policy may also specify the retention time of the backup. Without departing from the technology, the data protection policy may include additional and / or different information.

[0083] In step 316, the proxy service is notified by the data manager that the unique ID now exists in the system and is associated with the data protection policy.

[0084] The flag associated with the unique ID is updated to FINAL in step 318. The FINAL flag indicates that the asset associated with the unique ID is now being protected by the data manager.

[0085] In step 320, the unique ID is transmitted by the proxy service to the proxy.

[0086] The unique ID is stored by the agent in the agent record in step 322. After this step, the method ends.

[0087] While the foregoing description describes storing a unique ID for an asset in the agent, agent service, and data manager, each of the components may store additional information (see, e.g., Figure 1.3 ) and / or different information about the asset. In addition, the aforementioned components do not necessarily store the same information about the asset; therefore, some components may store more or less information about the asset without departing from the technology.

[0088] Reference now Figure 3.2 , Figure 3.2 A method for processing and verifying a backup request by a proxy is shown. The method is provided by a proxy service ( Figure 1.1 , 202). By default, the system is configured to perform data protection only on assets identified with a unique ID, where such assets are associated with a data protection policy in the data manager. In some embodiments, enforcement of the policy is performed by an agent service. Other components can perform the enforcement without departing from the technology.

[0089] Go to Figure 3.2 In step 324, the agent receives a backup request to back up a specific database. The backup request includes a unique ID of the asset.

[0090] In step 326, it is determined whether the unique ID of the asset specified in the backup request has been marked as FINAL. The backup operation can be performed on the system only if the associated unique ID has been marked as FINAL, because the FINAL mark indicates that the asset associated with the unique ID is associated with a data protection policy.

[0091] If the unique ID is marked as FINAL, the method proceeds to step 328 ; if the associated unique ID has not been marked as FINAL, the method proceeds to step 330 .

[0092] In step 328, the proxy service transmits the backup request for the asset with the associated FINAL unique ID from step 324 to the proxy. By only allowing backup requests for assets with the associated FINAL unique ID, it is ensured that any asset backed up on the system will have the protection policy associated with the unique ID attached. After the proxy receives the backup request, the proxy initiates the backup of the appropriate asset (e.g., a database). After the backup is successfully completed, information about the successful backup is propagated to the data manager (via the proxy service). The initiation of the backup process can include the proxy instructing the asset to start a backup operation to copy data from the asset to the backup storage system.

[0093] Backup requests for assets with associated unique IDs that are not marked as FINAL are blocked in step 330. If the unique ID is not marked as FINAL, the backup request cannot be transmitted because it means that the unique ID has not been verified to be consistent with that stored in the data manager.

[0094] Although not in Figure 3.2 , but the proxy service may also block other operations on the asset, such as replica discovery, until the unique ID is associated with the FINAL marker.

[0095] Performing replica discovery

[0096] Once the asset is associated with the unique ID, all copies of the backup are also associated with the unique ID. More specifically, after the asset is associated with the unique ID, this information is propagated to the appropriate agent (see, e.g., step 332). When a subsequent backup request is received from the asset, the agent passes the unique ID to the asset and initiates a backup of the asset. The result of backing up the asset is: (i) a backup of the asset stored on the backup storage system; and (ii) one or more entries are added to the local directory of the asset, where each of the entries references (or otherwise corresponds to) a portion of the backup and is labeled with the unique ID.

[0097] At a later point in time, the data manager may need to identify all copies (ie, backups) of the asset. This information can be used by the data manager, for example, to manage a retention policy for the copies (eg, determining which copies of the asset to delete from the backup storage system).

[0098] Figure 4.1 A flow chart illustrating a method for identifying replicas of a database using a unique ID. Figure 4.1 The method shown in can be used by, for example, an agent ( Figure 1.1 , 206) is executed. Without departing from the scope of the present invention, Figure 1.1 to Figure 1.2 Other components of the system can perform Figure 4.1 all or part of the method.

[0099] All or part of the method shown can be performed by one or more components of the system. Although the various steps in the flow chart are presented and described sequentially, it will be appreciated by those skilled in the art that some or all of the steps can be performed in a different order, can be combined or omitted, and some or all of the steps can be performed in parallel.

[0100] refer to Figure 4.1 , Figure 4.1 A method for identifying a copy of an asset and associating the copy with the asset is shown. The method is performed by an agent ( Figure 1.1 , 206) execute.

[0101] Go to Figure 4.1 , in step 400, the agent receives a replica discovery request for an asset (eg, a database). The replica discovery request may be received from a data manager (via the agent service) and may include a unique ID.

[0102] In step 402, a local directory for the database is obtained by the agent. More specifically, the agent can extract the unique ID in the replica discovery request and then perform a query on the agent record to identify the agent record with the unique ID. The agent can then use the contents of the agent record (see, e.g. Figure 1.3 ) to identify the asset. Once the asset is identified, the agent can make a request to the asset to obtain the local catalog.

[0103] In step 404, one or more backups (or portions thereof) are identified in the local directory. More specifically, the entries in the local directory are analyzed to identify entries that are marked with a unique identifier (i.e., the unique identifier specified in the replica discovery request). If the local directory includes other entries that are not marked and / or are associated with different unique IDs, then these entries are skipped in step 404 because they do not include the particular unique ID. Information about the identified backups (i.e., the identified entries) is provided to the data manager (via the proxy service).

[0104] The data manager may store this information in an appropriate data manager record (eg, a data manager record with a unique ID) and then use this information to manage backup of the asset.

[0105] Example

[0106] Go to Figure 4.2 , consider that the primary database is discovered and associated with A's unique ID (via Figure 3.1 At a later point in time, a backup database A (i.e., backup A) is generated. Backup A includes three parts (backup part 1, backup part 2, backup part 3). In addition, as part of the backup operation, three corresponding entries are created in the local directory for database A (i.e., local directory A), where each of the entries is marked with a unique ID A (i.e., backup part 1-UID A, backup part 2-UID A, backup part 3-UID A).

[0107] The data manager then performs a replica discovery for the asset with the unique ID of A (i.e., for database A), based on Figure 4.1 As a result of the replica discovery, the data manager identifies three entries in local directory A and applies retention policy X to these entries, with a retention period of 14 days.

[0108] refer to Figure 4.3 , after backup A is created, a restore operation is performed using backup A to generate a development database of database A (i.e., database B(Dev)). As part of the restore operation, a local directory B is created, where local directory B is a copy of local directory A. Database B is then discovered and associated with B's unique ID (via Figure 3.1 method shown).

[0109] At some later point in time, a backup database B (i.e., Backup B) is generated. Backup B includes three parts (Backup Part 4, Backup Part 5, Backup Part 6). In addition, as part of the backup operation, three corresponding entries are created in the local directory for database A (i.e., Local Directory B), where each of the entries is marked with 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 Directory B has six entries.

[0110] The data manager then performs a replica discovery for the asset with B's unique ID (i.e., for database B), based on Figure 4.1As a result of replica discovery, the data manager identifies three entries in local directory B that are associated with B's unique ID and applies retention policy Y to these entries, with a retention period of five days. Although local directory B has six entries, only three entries have B's unique ID, so only these entries are identified during replica discovery.

[0111] Before implementing unique IDs and tagging replicas with unique IDs, Figure 4.2 and Figure 4.3 In the scenario shown in , the replica discovery performed on local directory B will result in incorrect identification of six entries. Therefore, the six entries will be subject to retention policy Y (where backup part 1, backup part 2, and backup part 3 will also be associated with retention policy X). As a result, backup part 1, backup part 2, and backup part 3 will be deleted after five days instead of 14 days as expected by the user. As a result, the data of database A may be unavailable.

[0112] End of Example

[0113] Assignment of a unique ID to a previously protected asset

[0114] Consider a scenario where a system includes an asset (e.g., a database) that has been protected by a data manager using a mechanism that does not use unique identifiers. At a later point in time, the data manager is upgraded to protect the asset using unique identifiers. After the update, the system implements Figure 3.1 to Figure 3.2 However, as described above, once the data manager is upgraded to use unique identifiers, the proxy service blocks backup requests and replica discovery requests for assets and replicas that do not have unique identifiers. Thus, for example, if at time 1, database A has five backups, and at time 2, the data manager is upgraded, replica discovery cannot be performed on database A until database A is associated with a unique identifier (see, e.g., Figure 3.1 ), and during this transition period, replica discovery cannot occur (i.e., replica discovery is blocked, see e.g. Figure 3.2 ). Therefore, during the transition period, since replica discovery of database A cannot occur, all replicas of database A may not be discovered by (or known to) the data manager. If a restore is needed during the transition period, and the data manager is not aware of all replicas of database A, this may result in data unavailability.

[0115] To solve this problem, Figure 5 A flow chart illustrating a method for associating a unique ID with a previously protected asset. Figure 5 The method shown in can be performed by, for example, the data manager (102), the agent (206) and the agent service (202). Without departing from the scope of the present invention, Figure 1.1 to Figure 1.2 Other components of the system can perform Figure 5 all or part of the method.

[0116] All or part of the method shown can be performed by one or more components of the system. Although the various steps in the flow chart are presented and described sequentially, it will be appreciated by those skilled in the art that some or all of the steps can be performed in a different order, can be combined or omitted, and some or all of the steps can be performed in parallel.

[0117] Go to Figure 5 In step 500, the database identifier is transmitted by the agent to the agent service. Step 500 is similar to Figure 3.1 The step 300 in is basically the same.

[0118] In step 502 , it is determined whether there is an existing unique ID corresponding to the database identifier received by the proxy service from the proxy. If there is a corresponding unique ID, the method ends; if there is no corresponding unique ID, the method proceeds to step 504 .

[0119] The determination in step 502 includes generating a unique ID from the database identifier (discussed above) and then performing a lookup in the proxy service records to determine if there is an existing proxy service record that includes the unique ID.

[0120] continue Figure 5 As discussed above, in step 504, it is determined whether there is at least one replica of the database corresponding to the database identifier received by the proxy service from the proxy. If there is at least one replica of the database, the method proceeds to step 506. However, if there is no replica, the method proceeds to step 507. Figure 3.1 Specifically, the unique ID is marked with a NEW flag, and the method proceeds to Figure 3.1 Step 306 in .

[0121] return Figure 5 , with respect to step 504, prior to the determination, replica discovery had previously been performed (i.e., performed by the data manager prior to the upgrade), and therefore, the proxy service record includes information about replicas of the database identified during this process. Thus, the determination in step 504 includes using the database identifier to determine whether any replicas of the database were previously identified (i.e., whether there is at least one replica of the database).

[0122] continue Figure 5In step 506, the proxy 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 the data manager record for subsequent use (e.g., when the asset is discovered after an upgrade (see, e.g., Figure 3.1 )). In step 510, the unique ID is sent to the agent, which then stores the unique ID in the asset record.

[0123] In step 512, replica discovery of the database is initiated on the agent by the agent service. Since the unique ID is marked as DIRTY, replica discovery is performed without using a unique identifier. Therefore, all replicas of the database specified in the local directory of the database are identified and considered as replicas of the database.

[0124] In step 514, the agent notifies the agent service that the replica discovery process performed in step 512 has completed and all replicas of the database associated with the unique ID marked DIRTY have been discovered. The information obtained during replica discovery is stored in the agent service record and provided to the data manager as needed.

[0125] In step 516, the flag associated with the unique ID is updated to FINAL. Figure 3.2 As discussed, by setting the flag to FINAL, during the transition period, the data manager will be able to issue backup requests and replica discovery requests (and other similar requests) to the proxy service, and the proxy service will allow such requests to go forward because the unique ID is marked as FINAL.

[0126] Updates the database identifier for an asset

[0127] Consider a scenario where the system includes agents that generate database identifiers using a first function. At a later point in time, some of the agents are upgraded to use a second function to generate database identifiers. Further, in one embodiment, the first function (also referred to as R01 or a lower ranked function) results in a greater likelihood of generating the same database identifier for two different databases (i.e., a higher likelihood of conflict) than the second function (also referred to as R021 or a higher ranked function).

[0128] As discussed above, data identifiers are used to generate unique identifiers and are also used to link assets to unique identifiers (see, e.g. Figure 1.3 ). Thus, the data manager is enabled to support different versions of the agent (e.g., a legacy agent and a current agent). In addition, the agent 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.

[0129] Figure 6.1 to Figure 6.2 A flow diagram for performing an asset record update operation in accordance with one or more embodiments of the technology is shown. Figure 6.1 to Figure 6.2 The method shown in can be used by, for example, a data manager ( Figure 1.1 , 102) is executed. Without departing from the scope of the present invention, Figure 1.1 to Figure 1.2 Other components of the system can perform Figure 6.1 to Figure 6.2 all or part of the method.

[0130] All or part of the method shown can be performed by one or more components of the system. Although the various steps in the flow chart are presented and described sequentially, it will be appreciated by those skilled in the art that some or all of the steps can be performed in a different order, can be combined or omitted, and some or all of the steps can be performed in parallel.

[0131] Figure 6.1 to Figure 6.2 The method shown in enables legacy and current agents to provide (via an agent service) a database identifier to a data manager, and the data manager can determine whether the database identifier is associated with a new or previously discovered asset.

[0132] Go to Figure 6.1 In step 600, an asset notification for an asset is received, wherein the asset notification includes: (i) a database identifier in the case where the asset notification originates from a legacy agent or (ii) two database identifiers (represented using R01 and R02 (as discussed above)) in the case where the asset originates from a current agent (i.e., non-legacy agent).

[0133] 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 proceeds to step 604; otherwise, the method proceeds to Figure 6.2 , step 616.

[0134] In step 604, it is determined whether there is a data manager record including a database identifier generated using a higher ranking function (i.e., DID R02). If there is a data manager record including a database identifier generated using a higher ranking function, the process ends because the database has been discovered; otherwise, the process proceeds to step 606.

[0135] In step 606, it is determined whether there is a data manager record including a database identifier generated using a lower ranking function (i.e., DID R01). If there is a data manager record including a database identifier generated using a lower ranking function, the process proceeds to step 610; otherwise, the process proceeds to step 608.

[0136] In step 608, a new data manager record is created that includes two database identifiers (ie, DID R02 and DID R01). The process then ends.

[0137] In step 610, it is determined whether there is a data manager record including a database identifier generated using a lower ranking function (i.e., DID R01) and a different database identifier generated using a higher ranking function. If such a data manager record exists, the process proceeds to step 612; otherwise, the process proceeds to step 614.

[0138] In step 612, a new data manager record is created that includes two database identifiers (i.e., DID R02 and DID R01). The process then ends. Step 612 considers the following scenario: There are two different assets that have the same database identifier generated using the lower-ranked function (i.e., the database identifier generated using R01 conflicts), but have different database identifiers generated using the higher-ranked function.

[0139] In step 614, the database identifier generated using the higher ranked function is added to the existing record that includes only database identifiers generated using the lower ranked function. The process then ends. Step 614 considers a scenario where an asset was previously discovered by a legacy agent and has now been discovered by a current (i.e., non-legacy) agent.

[0140] Reference now Figure 6.2 If the asset notification does not include multiple database identifiers (DIDs), then in step 616, it is determined whether there is a data manager record that includes a database identifier generated using a lower-ranked function (i.e., DID R01). If there is a data manager record that includes a database identifier generated using a lower-ranked function, the process proceeds to step 620; otherwise, the process proceeds to step 618.

[0141] In step 618, a new data manager record is created that includes a database identifier (ie, DID R01). The process then ends.

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

[0143] Step 620 considers the following scenario: there are two different assets, both assets have the same database identifier generated using the lower ranked function (i.e., there is a conflict), and the data manager includes a data manager record, the data manager record includes both DID R01 and the database identifier generated using the higher ranked function. In this scenario, the asset that is the subject of the record was previously discovered using the current (i.e., non-legacy) proxy, which resulted in the record having two database identifiers.

[0144] In step 622, a new data manager record is created that includes a database identifier (ie, DID R01). The process then ends.

[0145] As noted above, the embodiments described herein may be implemented using a computing device. Figure 7 A diagram of a computing device according to one or more disclosed embodiments is shown. The computing device (700) may include one or more computer processors (702), non-persistent storage devices (704) (e.g., volatile memory, such as random access memory (RAM), cache memory), persistent storage devices (706) (e.g., hard disk, optical drive such as compact disk (CD) drive or digital versatile disk (DVD) drive, flash memory, etc.), communication interfaces (712) (e.g., Bluetooth interface, infrared interface, network interface, optical interface, etc.), input devices (710), output devices (708), and numerous other elements (not shown) and functionality. Each of these components is described below.

[0146] In one or more embodiments, the computer processor (702) can be an integrated circuit for processing instructions. For example, the computer processor can be one or more cores or micro-cores of a processor. The computing device (700) can also include one or more input devices (710), such as a touch screen, a keyboard, a mouse, a microphone, a touchpad, an electronic pen, or any other type of input device. In addition, the communication interface (712) can 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 any other type of network) and / or another device, such as another computing device.

[0147] 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 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 devices. The input devices and output devices may be connected locally or remotely to the computer processor (702), the non-persistent storage device (704), and the persistent storage device (706). There are many different types of computing devices, and the aforementioned input devices and output devices may take other forms.

[0148] The problems discussed above should be understood as examples of problems solved by the embodiments described herein, and the scope of the embodiments should not be limited to solving the same / similar problems. The disclosed technology can be widely applied to solve a range of problems beyond the problems discussed herein.

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

[0150] In the above description, there are references to database identifiers. Those skilled in the art who have the benefit of this detailed description will understand that when the asset is a database, the database identifier corresponds to the asset identifier. In addition, while various embodiments are described with respect to a database, embodiments of the technology may be implemented for other types of assets (e.g., storage volumes) without departing from the technology.

[0151] In the above description, numerous details are set forth as examples of the embodiments described herein. Those skilled in the art who benefit from this detailed description will appreciate that one or more of the embodiments described herein may be practiced without these specific details, and that numerous changes or modifications may also be possible without departing from the scope of the embodiments described herein. Certain details known to those of ordinary skill in the art may be omitted to avoid obscuring the description.

[0152] In the above description of the drawings, any component described with respect to a drawing may be equivalent to one or more similarly named components described with respect to any other drawing in the various embodiments described herein. For the sake of brevity, the description of these components will not be repeated with respect to each drawing. 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. In addition, according to the various embodiments described herein, any description of the components of the drawings should be interpreted as an optional embodiment, which can be implemented in addition to, in conjunction with, or in place of the corresponding similarly named component descriptions in any other drawings.

[0153] Throughout this application, elements of the drawings may be labeled B to C or D to E. As used herein, the aforementioned labeling means that an element may include any number of items, and does not require that an element include the same number of elements as any other item labeled B to C or D to E. For example, a data structure may include a first element labeled B and a second element labeled C. This labeling convention means that a data structure may include any number of elements. A second data structure, also labeled B to C or D to E, 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.

[0154] Throughout this application, ordinal numbers (e.g., first, second, third, etc.) may be used as adjectives for elements (i.e., any noun in this application). Unless explicitly disclosed, such as by using the terms "before," "after," "single," and other such terms, the use of ordinal numbers does not imply or create any particular order of elements, nor does it limit any element to only a single element. Instead, the use of ordinal numbers is to distinguish elements. By way of example, a first element is different from a second element, and a first element may encompass more than one element and follow (or precede) the second element in element order.

[0155] As used herein, the phrases operatively connected or operable connection refer to the presence of a direct or indirect connection between elements / components / devices that allows the elements to interact in some manner. For example, the phrase 'operatively connected' may refer to any direct connection (e.g., a direct wired connection between two devices or components) or indirect connection (e.g., wired and / or wireless connections between any number of devices or components that connect operatively connected devices). Thus, any path that information may pass through may be considered an operative connection.

[0156] Although the embodiments described herein are described with respect to a limited number of embodiments, those skilled in the art having benefit of this detailed description will appreciate that other embodiments may be envisioned that do not depart from the scope of the embodiments as disclosed herein. Accordingly, the scope of the embodiments described herein should be limited solely by the appended claims.

Claims

1. A method for managing a database, the method comprising: receiving a database identifier (DID) of the database; generating a unique identifier (UID) for the database using the DID; After said generating, determining that said database is associated with a data protection policy; as well as Allowing backup operations specifying the UID to be serviced by an agent operatively connected to the database.

2. The method of claim 1, wherein the DID is obtained from the proxy.

3. The method of claim 1 , wherein determining that the database is associated with the data protection policy comprises: receiving a notification from a data manager that the database associated with the UID is protected by the data protection policy, Wherein the agent executes on a host operatively connected to the database, and wherein the data manager executes 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 a proxy service record, wherein the tag has a value of NEW, After receiving the notification, the value of the flag is updated to FINAL. The method of claim 4 , wherein the proxy service record further comprises the DID.

6. The method of claim 4, further comprising: After the updating, the UID is sent to the agent, wherein the agent stores the UID and the DID in an agent record.

7. The method of claim 1, further comprising: After said generating, sending said UID to a data manager; receiving, after said sending and before said determining, a backup request specifying said UID from said data manager, In response to receiving the backup request, determining that the UID is not associated with any data protection policy, In response to determining that the UID is not associated with any data protection policy, preventing the backup request from being sent to the agent.

8. A non-transitory computer readable medium comprising a computer readable program code, which when executed by a computer processor enables the computer processor to perform a method for managing a database, the method comprising: receiving a database identifier (DID) of the database; generating a unique identifier (UID) for the database using the DID; After said generating, determining that said database is associated with a data protection policy; as well as Allowing backup operations specifying the UID to be serviced by an agent operatively connected to the database.

9. The non-transitory computer-readable medium of claim 8, wherein the DID is obtained from the proxy.

10. The non-transitory computer-readable medium of claim 8, wherein determining that the database is associated with the data protection policy comprises: receiving a notification from a data manager that the database associated with the UID is protected by the data protection policy, Wherein the agent executes on a host operatively connected to the database, and wherein the data manager executes 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 a proxy service record, wherein the tag has a value of NEW, After receiving the notification, the value of the flag is updated to FINAL.

12. The non-transitory computer-readable medium of claim 11, wherein the proxy service record further comprises the DID.

13. The non-transitory computer readable medium of claim 11, wherein the method further comprises: After the updating, the UID is sent to the agent, wherein the agent stores the UID and the DID in an agent record.

14. The non-transitory computer readable medium of claim 8, wherein the method further comprises: After said generating, sending said UID to a data manager; receiving, after said sending and before said determining, a backup request specifying said UID from said data manager, In response to receiving the backup request, determining that the UID is not associated with any data protection policy, In response to determining that the UID is not associated with any data protection policy, preventing the backup request from being sent to the agent.

15. A system comprising: an agent executing on the system and operatively connected to a database; as well as The proxy service, which executes on the system, is configured to: receiving a database identifier (DID) of the database, wherein the DID is obtained from the agent; generating a unique identifier (UID) for the database using the DID; After said generating, determining that said database is associated with a data protection policy; as well as Allows backup operations specifying the UID to be serviced by the agent.

16. The system of claim 15, wherein determining that the database is associated with the data protection policy comprises: receiving a notification from a data manager that the database associated with the UID is protected by the data protection policy, Wherein the agent executes on a host operatively connected to the database, and wherein the data manager executes 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 a proxy service record, wherein the tag has a value of NEW, After receiving the notification, the value of the flag is updated to FINAL.

18. The system of claim 17, wherein the proxy service record further comprises the DID.

19. The system of claim 17, further comprising: After the updating, the UID is sent to the agent, wherein the agent stores the UID and the DID in an agent record.

20. The system of claim 15, wherein the proxy service is further configured to: After said generating, sending said UID to a data manager; receiving, after said sending and before said determining, a backup request specifying said UID from said data manager, In response to receiving the backup request, determining that the UID is not associated with any data protection policy, In response to determining that the UID is not associated with any data protection policy, preventing the backup request from being sent to the agent.

Images