Enforcing full backup when role switching occurs in database in high availability configuration

Abstract

In general, embodiments relate to a method for backing up a database, the method comprising: receiving a first backup request, where the first backup request specifies a role and an asset group identifier for an asset group; identifying a database with the role in the asset group based on the first backup request; determining that the role of the database has changed since a last backup of the group of assets; and in response to the determination, issuing a second backup request for the database, where the second backup request is for full backup.

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 present technology will be described with reference to the accompanying drawings. However, the drawings only illustrate certain aspects or implementations of the present technology by way of example and are not meant to limit the scope of the claims.

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

[0004] Figure 1.2 A diagram showing the configuration of a database according to one or more embodiments of the present technology.

[0005] Figure 2 A flowchart of a method for performing discovery in accordance with one or more embodiments of the present technology is shown.

[0006] Figure 3.1 to Figure 3.3 A flowchart of a method for backing up a database according to one or more embodiments of the present technology is shown.

[0007] Figure 4.1 to Figure 4.3 A flowchart of a method for backing up a database according to one or more embodiments of the present technology is shown.

[0008] Figure 5 A flowchart of a method for backing up a database according to one or more embodiments of the present technology is shown.

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

[0010] Detailed description will now be given with reference to the accompanying drawings.

[0011] Generally speaking, embodiments of the present technology involve backing up assets, where the assets are arranged in a high availability configuration (see, e.g. Figure 1.2 In the context of the present 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 determining how and when to back up assets in a manner that efficiently utilizes system resources.

[0012] Reference now Figure 3.1 to Figure 3.3 In one embodiment of the present technology, backup is scheduled for assets of an asset group with a primary role. In this embodiment, the protection policy ensures that assets with a primary (as opposed to a specific asset) role are always protected. As will be discussed in further detail below, the role associated with an asset may change over time. Therefore, an asset may initially have a primary role, and then subsequently be converted to a standby role or offline (i.e., become unavailable). If the protection policy is based on a specific asset (e.g., database A) rather than an asset with a primary role, there is a scenario in which the asset may be unavailable and therefore the asset will not be backed up. However, if the protection policy is based on backing up assets with a primary role, the asset with a primary role will always be backed up. In other words, in a high availability configuration with multiple assets, there will be one asset with a primary role at any given time. When a backup of an asset with a primary role is initiated, it will be determined which asset currently has the primary role, and then the asset of this identification will be backed up. This method enables the protection policy to be based on roles, which essentially takes into account the dynamic nature of role associations in a high availability configuration.

[0013] Reference now Figure 4.1 to Figure 4.3 As shown, in one embodiment of the present technology, backups are scheduled as assets of an asset group with a backup role. In this embodiment, the protection policy ensures that assets with a backup (as opposed to a specific asset) role are always protected. This approach enables protection policies to be role-based, which inherently takes into account the dynamic nature of role associations in a high availability configuration.

[0014] Reference now Figure 5 In one embodiment of the present technology, if a role change is detected on an asset, proactive steps may be taken to ensure that a full backup is performed for such asset. More specifically, if an incremental backup is scheduled for an asset in an asset group, and the last backup performed for this asset group was not for this asset, a full backup is performed instead of an incremental backup. By promoting an incremental backup to a full backup, this embodiment eliminates (or substantially eliminates) the resources required to determine what needs to be part of the incremental backup. In other words, if the last backup of the asset group was not performed for the asset that is now being backed up, the incremental backup for this asset will be relative to the last backup of this asset (rather than relative to the last backup of the asset group), and therefore will be quite large. Therefore, by detecting a role change (as described above) and then using this detection to force a full backup, the resources required to determine which parts of the asset should be included in the incremental backup are not occupied.

[0015] The above three methods can be used together or separately and can be used in Figures 1 to Figure 1.2 and Figure 6 is implemented on the system shown.

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

[0017] Figure 1.1 A diagram of a system according to one or more embodiments described herein is shown. 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.

[0018] In one or more embodiments, Figure 1.1 The components in 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 include 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.

[0019] 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, 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 may store computer instructions, such as computer code, which (when executed by one or more processors of the computing device) causes the computing device to perform the functions described herein and / or to perform operations in the computing device. Figures 2 to 5 The data manager (102) may be implemented using other types of computing devices without departing from the embodiments disclosed herein. For additional details on computing devices, refer to Figure 6 .

[0020] 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.

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

[0022] In one or more embodiments, the data manager record (104) includes records (or entries) about assets (e.g., database (400)) that the data manager (102) is protecting (i.e., performing backup services for). The record for each of the assets may include, but is 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 data manager (102) to perform the methods described herein. In addition, the data manager record (104) may include, but is not limited to, a backup policy (or protection policy) that describes which assets to back up, when to back up such assets, and the type of backup to generate (e.g., incremental or full). In addition, the data manager record (104) may be stored in any type of volatile and / or persistent storage device using one or more data structures of any type.

[0023] 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) in the host (200), as described in detail below.

[0024] In one or more embodiments, the host (200) 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, a distributed computing system, or a cloud resource. The computing device may include one or more processors, a memory (e.g., a random access memory), and a persistent storage device (e.g., a disk drive, a solid-state drive, etc.). The persistent storage device may store computer instructions, such as computer code, which (when executed by one or more processors 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. Figures 2 to 5 The host (200) may be implemented using other types of computing devices without departing from the embodiments disclosed herein. For additional details on the computing device, refer to Figure 6 .

[0025] 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.

[0026] In one or more embodiments, the host (200) may include functionality to discover assets, or be otherwise configured to discover assets, and to 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 Figures 2 to 5 The host (200) may include other and / or additional functionality without departing from the embodiments disclosed herein.

[0027] In one or more embodiments, the agent service (202) can be a physical or logical component of a host that provides a communication bridge between the data manager (102) and the agents (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 record (204) and the agent (206).

[0028] In one or more embodiments, the agent service record (204) includes records (or entries) about assets (e.g., database (400)) that have been discovered by the agent (206). The record for each of the assets can include, but is 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.

[0029] 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 for discovering assets and executing backup jobs orchestrated by the data manager (102), where the backup jobs are transmitted 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).

[0030] In one or more embodiments, the agent record (208) includes records (or entries) about assets (e.g., database (400)) that the agent (206) has discovered. The record for each of the assets may include, but is 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.

[0031] 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 one or more processors 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. Figures 2 to 5 The backup storage system (300) may be implemented using other types of computing devices without departing from the embodiments disclosed herein. For additional details on the computing device, refer to Figure 6 .

[0032] 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 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.

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

[0034] 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 be of the same type and may not co-exist on 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.

[0035] 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 present technology. Figure 1.1 The components in are shown as distinct components, but one or more of these components may co-exist on the same physical hardware without departing from the present technology.

[0036] In addition, although Figure 1.1 One host is shown, but the system may include multiple hosts, where each host includes a service agent and one or more agents. The present technology is not limited to this configuration.

[0037] Now go to Figure 1.2 , Figure 1.2 A database (400) according to one or more embodiments of the present technology is shown. 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 such a configuration, each database is assigned a role, e.g., 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 this database and write data to this database. The database (400) includes the function of replicating (or otherwise copying) data from a database having a primary role to a database having a backup role (e.g., 404B, 404C, 404D, 404E).

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

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

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

[0042] Database discovery process

[0043] Figure 2 A flow chart of a method for discovering a database according to one or more embodiments of the present technology is shown. Figure 2The method shown can be implemented, for example, on a host computer (e.g., Figure 1.1 , 206) is executed by an agent executed on the server. Without departing from the scope of the present invention, Figure 1.1 to Figure 1.2 Other components of the system can execute Figure 2 All or part of the method.

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

[0045] 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 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).

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

[0047] In step 202, the agent obtains information about the database. The information about the database includes, but is not limited to, a database identifier, a group identifier, and a current role of the database. Without departing from the present technology, the information about the database may include additional and / or different information.

[0048] A database identifier corresponds to a string of letters, numbers, or alphanumeric characters used to identify a database. The database identifier may be generated (or otherwise derived) from information associated with the database. For example, various attributes of the database may be obtained, and a hash function may then be applied to these attributes in order to generate the database identifier. Other methods for generating a database identifier may be used without departing from the present technology.

[0049] The group identifier (also called asset group identifier) ​​corresponds to a string used to identify the asset group to which the database belongs (see, for example, Figure 1.2 ). In some scenarios, the group identifier may not be available from the database; instead, the group identifier may be generated by the agent, agent service, and / or data manager.

[0050] In scenarios where the database is part of a high availability configuration, the database can be in the role of primary, physical standby, or logical standby (see e.g. Figure 1.2 ). In such a scenario, the role currently associated with the discovered database can be stored with the database, and during discovery, the role of the database can be obtained.

[0051] Continue the discussion Figure 2 In step 204, the agent stores the information obtained in step 202 in the agent record ( Figure 1.1 , 208).

[0052] In step 206, the agent transmits the information in step 202 to the data manager ( Figure 1.1 , 102). In one embodiment, the agent transmits the database information to the agent service (see, e.g. Figure 1.1 After receiving the database information, the proxy service may store a copy of the information and then transmit the information to the proxy management module (106, Figure 1.1 ) is transferred to a data manager (see e.g. Figure 1.1 102 in the above).

[0053] Figure 2 The illustrated method may be performed continuously to track the addition and removal (or unavailability) of databases in the system as well as changes in the roles of databases within the system.

[0054] The information obtained during the discovery process is used to enable Figure 3.1 to Figure 5 The role-based backup approach described in .

[0055] The data manager can manage data protection for multiple asset groups, and can protect each of the asset groups using any combination of the methods described herein.

[0056] Schedule backup of the primary database for the asset group

[0057] Traditionally, databases are each protected as a separate entity, and the associated backup policy specifies a particular database to be backed up (eg, a full backup of Database A is performed every 24 hours, and an incremental backup of Database A is performed every 2 hours).

[0058] In addition to ensuring that the data in the database is protected (i.e., there are backup copies of the data), users often also want to ensure that their data is easily accessible. To achieve this goal, a high availability configuration can be implemented (see e.g. Figure 1.2). While this approach supports access to data, for example, when a database with the primary role becomes unavailable, a database with the physical standby role is promoted to the primary role, thereby enabling users to continue to access their data. While this approach enables users to continue to access their data, because traditional methods of backing up databases are based on specifying a specific database, when the role of a database changes (e.g., as outlined in the scenario above), then the backup policy is no longer effective, for example, because the backup policy specifies a database that has become unavailable.

[0059] The traditional approach to addressing the potential gaps in backup protection described above is to back up multiple databases in a given asset group; however, this results in increased load on the databases and backup storage systems and duplication of data in the backup storage systems (i.e., there will be multiple backup copies). Furthermore, unless all databases in an asset group are backed up, there will still be scenarios where the backup strategy will attempt to back up an unavailable database.

[0060] In order to solve the above problems with traditional methods, the embodiments of the present technology focus on role-based backup strategies (i.e., strategies do not specify a given database, but specify the database with the primary role). In this way, even if there is a role switch, the data in the asset group will continue to be protected.

[0061] Figure 3.1 to Figure 3.3 A flow chart of a method for scheduling a backup of a primary database of a group in accordance with one or more embodiments of the present technology is shown. Figure 3.1 to Figure 3.3 The method shown in can be performed by, for example, a data manager (102). Without departing from the scope of the present invention, Figure 1.1 to Figure 1.2 Other components of the system can execute Figure 3.1 to Figure 3.3 All or part of the method.

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

[0063] refer to Figure 3.1 , Figure 3.1 Shows a method to ensure that a full backup of the primary database is performed. This method is performed by the Data Manager ( Figure 1.1 , 102) execute.

[0064] Go to Figure 3.1In step 300, a backup request to back up a database having a primary role of an asset group is received by the data manager. As discussed above, the data manager maintains a backup policy for the asset group, wherein the backup policy specifies the asset group, the role of the database to be backed up, the type of backup (e.g., full or incremental (or partial)), and the frequency of the backup. In addition, the data manager includes functionality to track the backup policy and initiate a backup (via a backup request) based on the backup policy.

[0065] In step 302, it is determined whether the backup request received by the data manager is for a full backup. If the backup request is for a full backup, the method proceeds to step 304; if the backup request is not for a full backup (i.e., the backup request is for an incremental backup), the method proceeds to step 310.

[0066] In step 304, the data manager identifies which database in the asset group currently has the primary role. The identification in step 304 is based on the information of the asset group maintained in the data manager record. As discussed above, the agent (e.g., Figure 1.1 The identification in step 304 uses the group identifier (which was included in the request in step 300) to perform a lookup in the data manager record to identify all databases associated with the asset group, and then identify the specific database associated with the primary role.

[0067] In step 306 , a backup is scheduled for the specific database identified in step 304 .

[0068] In step 308, a backup request for a full backup of the identified database is issued by the data manager to the agent. More specifically, the data manager issues the backup request to the appropriate agent service (i.e., to the agent service on the host that is executing the agent that will ultimately service the backup request). The agent service then sends the backup request to the appropriate agent. The agent then executes Figure 3.2 The process shown in .

[0069] Returning to the discussion of step 302, if the backup request is not for a full backup (i.e., the backup request is for an incremental backup), the data manager identifies which database in the asset group currently has the primary role in step 310. Step 310 is performed in the same or substantially the same manner as step 304.

[0070] In step 312, the database in the asset group from which the last full backup was performed is identified. In one embodiment, when a backup of a database in an asset group is successfully performed, information about the database for which the backup was performed is tracked. Thus, for a given asset group, the data manager record may specify all backups performed on the databases in the asset group, and for each backup, the specific database and the type of backup (e.g., full backup or incremental backup) that were backed up. Thus, the identification in step 312 may involve searching a list of backups performed on the databases in the asset group, identifying the last successful full backup, and determining which database the last successful full backup was performed on.

[0071] In step 314, it is determined whether the database identified in steps 310 and 312 is the same database. In other words, the data manager is checking whether the database currently associated with the primary role in the data manager record for the asset group is the same as the database of the last successful full backup. If the identified databases are the same, the method proceeds to step 316; if the identified databases are not the same, the method proceeds to step 306.

[0072] In step 316, a non-full backup (eg, an incremental backup) is scheduled for the database identified in step 310. Once the non-full backup is scheduled, the method proceeds to step 308.

[0073] Reference now Figure 3.2 , Figure 3.2 A method for processing a scheduled backup request by an agent is shown. The method is performed by the agent ( Figure 1.1 , 206) execute. Figure 3.2 The method shown occurs after step 308 .

[0074] Go to Figure 3.2 , in step 318, a backup request to back up a specific database is received by the agent.

[0075] In step 320, the agent obtains the role of the database from the agent record. As discussed above, the agent continuously executes Figure 2 The method shown, and therefore, the agent has the latest information about the database in the asset group. Therefore, although this information is eventually propagated to the data manager, due to the dynamic nature of the high availability configuration, the information in the data manager record may be "outdated" (i.e., not the latest).

[0076] In step 322 , the role of the database is determined (ie, the role of the database specified in the backup request). If the database role obtained from the proxy record indicates that the database has a primary role, the method proceeds to step 324 ; otherwise, the method proceeds to step 326 .

[0077] In step 324, a backup process is initiated for the database identified in step 322. Upon successful completion of the backup, information about the successful backup is propagated to the data manager (via the agent service). The initiation of the backup process may include the agent instructing the database to initiate a backup operation to copy data from the database to the backup storage system.

[0078] Returning to step 322, if the database role obtained from the agent record indicates that the database does not have the primary role, an error notification is issued to the data manager (via the agent service) in step 326. Since the agent identified by the particular database does not currently have the primary role, a backup cannot be started for the database.

[0079] Reference now Figure 3.3 , Figure 3.3 Shown for responding to Figure 3.2 The method for generating the error message in step 326 of the data manager. This method is performed by the data manager ( Figure 1.1 , 102) execute.

[0080] Go to Figure 3.3 In step 328, the data manager receives an error notification: the specified asset group (i.e., Figure 3.1 In the method shown, the database identified in step 304 or 310 has had a role change and a backup has not been performed on the specified database.

[0081] In step 330, a discovery process is initiated by the data manager for all databases in the asset group. In this embodiment, the data manager is searching to identify databases with primary roles in the asset group so that backup requests can be scheduled. Step 330 includes instructing the agent (via the agent service) to perform discovery on the asset group (see, e.g., Figure 2 ) to obtain the latest information about asset group membership (i.e., which databases belong to the asset group) and the role of each of those databases.

[0082] In step 332, a determination is made as to whether the discovery process initiated by the data manager has been completed. The determination in step 332 is based on receiving a confirmation from the discovery of the asset group that it has been completed. If the discovery process is complete, the method proceeds to Figure 3.1 ; otherwise, the method proceeds to step 334.

[0083] In step 334, the data manager waits until the discovery process is complete and checks the progress incrementally. To check whether the process is complete, the method returns to step 332.

[0084] Schedule backups of secondary databases for asset groups

[0085] Figure 4.1-Figure 4.3 The method in this paper also solves the above problem about Figure 3.1 to Figure 3.3 outlined problem; however, Figure 4.1 to Figure 4.3 In the embodiment shown in , a backup is performed on a database with a standby role (which can be physical or logical). In addition, since a given asset group can have any number of databases with a standby role, this embodiment also addresses how to select a database with a standby role from a set of databases with a standby role.

[0086] Figure 4.1 to Figure 4.3 A flow chart of a method for scheduling a backup of a standby database of a group in accordance with one or more embodiments of the present technology is shown. Figure 4.1 to Figure 4.3 The method shown in Figure 1.1 As shown in , it is performed by, for example, the data manager (102) and the agent (206). Without departing from the scope of the present invention, Figure 1.1 to Figure 1.2 Other components of the system can execute Figure 4.1 to Figure 4.3 All or part of the method.

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

[0088] refer to Figure 4.1 , Figure 4.1 A method for ensuring that a full backup of the primary database is performed is shown. This method is performed by the Data Manager ( Figure 1.1 , 102) execute.

[0089] Go to Figure 4.1 In step 400, a backup request to back up a database having a standby role of an asset group is received by the data manager. As discussed above, the data manager maintains a backup policy for the asset group, wherein the backup policy specifies the asset group, the role of the database to be backed up, the type of backup (e.g., full or incremental), and the frequency of the backup. In addition, the data manager includes functionality to track the backup policy and initiate backups based on the backup policy.

[0090] In step 402, it is determined whether the backup request received by the data manager is for a full backup. If the backup request is for a full backup, the method proceeds to step 404; if the backup request is not for a full backup (i.e., the backup request is for an incremental backup), the method proceeds to step 410.

[0091] In step 404, the data manager identifies which database in the asset group currently has the standby role and has the highest preference. The identification in step 404 is based on the information of the asset group maintained in the data manager record. As discussed above, the agent (e.g., Figure 1.1 The identification in step 404 uses the group identifier (which was included in the request in step 400) to perform a lookup in the data manager record to identify all databases associated with the asset group, and then identify the specific database associated with the standby role. Once all databases associated with the standby role in the asset group are identified, the data manager determines the preference (or ranking) associated with each of the identified databases, and then selects the database with the highest preference.

[0092] The preferences associated with each of the databases having an alternate role may be set by a user, automatically by the data manager using heuristics, using another method, or using any combination thereof.

[0093] In step 406 , a backup is scheduled for the specific database identified in step 404 .

[0094] In step 408, a backup request for a full backup of the identified database is issued by the data manager to the agent. More specifically, the data manager issues the backup request to the appropriate agent service (i.e., to the agent service on the host that is executing the agent that will ultimately service the backup request). The agent service then sends the backup request to the appropriate agent. The agent then executes Figure 4.2 The process shown in .

[0095] Returning to the discussion of step 402, if the backup request is not for a full backup (i.e., the backup request is a request for an incremental backup), then in step 410, the database in the asset group from which the last full backup was obtained is identified. In one embodiment, when a backup of a database in an asset group is successfully performed, information about the database for which the backup was performed is tracked. Thus, for a given asset group, the data manager record may specify all backups performed on the databases in the asset group, and for each backup, the specific database and backup type (e.g., full backup or incremental backup) that were backed up. Thus, the identification in step 410 may involve searching a list of backups performed on the databases in the asset group, identifying the last successful full backup, and determining on which database the last successful full backup was performed.

[0096] In step 412, it is determined whether the database identified in step 410 has a standby role. If the identified database has a standby role, the method proceeds to step 414; if the identified database is not the same, the method proceeds to step 406.

[0097] In step 414, a non-full backup (eg, an incremental backup) is scheduled for the database identified in step 410. Once the non-full backup is scheduled, the method proceeds to step 408.

[0098] Reference now Figure 4.2 , Figure 4.2 A method for processing a scheduled backup request by an agent is shown. The method is performed by the agent ( Figure 1.1 , 206) execute. Figure 4.2 The method shown occurs after step 408 .

[0099] Go to Figure 4.2 , in step 418, a backup request to back up a specific database is received by the agent.

[0100] In step 420, the agent obtains the role of the database from the agent record. As discussed above, the agent continuously executes Figure 2 The method shown, and therefore, the agent has the latest information about the database in the asset group. Therefore, although this information is eventually propagated to the data manager, due to the dynamic nature of the high availability configuration, the information in the data manager record may be "outdated" (i.e., not the latest).

[0101] In step 422, the role of the database is determined (i.e., the role of the database specified in the backup request). If the database role obtained from the proxy record indicates that the database has a standby role and is available (i.e., the database is online), the method proceeds to step 424; otherwise, the method proceeds to step 426.

[0102] In step 424, a backup process is initiated for the standby database identified in step 422. Upon successful completion of the backup, information about the successful backup is propagated to the data manager (via the agent service). The initiation of the backup process may include the agent instructing the database to initiate a backup operation to copy data from the database to the backup storage system.

[0103] Returning to step 422, if the database role obtained from the proxy record indicates that the database does not have a standby role or is unavailable, an error notification is issued to the data manager (via the proxy service) in step 426. Because the proxy identified by the specific database does not currently have a standby role and / or the database is unavailable, a backup cannot be started for the database.

[0104] Reference now Figure 4.3 , Figure 4.3Shown for responding to Figure 4.2 The method for generating the error message in step 426 of the data manager. This method is performed by the data manager ( Figure 1.1 , 102) execute.

[0105] In step 428, an error notification is received by the data manager: a database identified in a specified asset group (ie, Figure 4.1 In the method shown in FIG. 4 , a database identified in step 404 or 410 has had a role change and / or the identified database is unavailable, and therefore a backup of the specified database is not performed.

[0106] In step 430, it is determined whether there are any other databases in the asset group that have a standby role. More specifically, since the asset group may include more than one standby database, the data manager attempts to perform a backup on another database in the asset group that has a standby role.

[0107] Continue the discussion Figure 4.3 If there is an available standby database (i.e., a database that has not yet been processed with the standby role), the method proceeds to Figure 4.1 404 in the. Figure 4.1 to Figure 4.3 The entire process can continue until a database with a standby role is backed up or it is determined that no database with a standby role exists to be backed up.

[0108] In one embodiment, when the method proceeds to step 404 via step 430, identifying a database with a standby role includes determining a database with a standby role that has the highest preference available and has not been attempted to be backed up during the immediate backup window. For example, assume a scenario where the database preferences from high to low are database A, database B, and database C. Further, assume that a first attempt is made to back up database A, and that attempt fails because database A now has the primary role. In response, the data manager can select database B to back up. If the attempt to back up database B fails because database B is unavailable, the data manager can select database C to back up.

[0109] Although Figure 4.1 to Figure 4.3 Not shown, if an attempt to back up a database with a standby role for an asset group ultimately fails, the data manager can trigger Figure 2 to discover databases in the asset group that have a standby role. Once these databases are identified, a preference is assigned to each database and then the Figure 4.1 to Figure 4.3 The method shown.

[0110] Force a full backup when there is a role change

[0111] As discussed above, Figure 3.1 to Figure 4.3A role-based backup strategy is utilized to effectively and efficiently back up databases that are part of a high availability configuration. However, when utilizing role-based backup where the role associated with a given database may change, there may be situations where an incremental backup is scheduled to be performed on a particular database (e.g., database A having a primary role, see e.g., Figure 3.1 ) is performed, but this database has only been assigned this role recently, for example, the role was assigned after the last backup was performed for the asset group but before a subsequent backup request was received for the asset group. In these scenarios, although incremental backups may be generated, it is possible to improve resource utilization of the system (and minimize performance impact) if a full backup is generated.

[0112] Figure 5 A flow chart illustrating a method for forcing a backup when a role of a database changes according to one or more embodiments of the present technology. Figure 5 The method shown can be implemented 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 execute Figure 5 All or part of the method.

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

[0114] refer to Figure 5 , Figure 5 Shows a method for ensuring that a full backup is forced after a role switch. This method is performed by the data manager ( Figure 1.1 , 102) execute.

[0115] Go to Figure 5 In step 500, the data manager ( Figure 1.1 , 102) receiving a backup request for an asset group. The backup request specifies the asset group and a specific database role (eg, primary or standby) required to perform the backup.

[0116] In step 502, the data manager ( Figure 1.1 , 102) identifies which database in the asset group is currently using the primary role or the standby role. If the database role is primary, you can Figure 3.1 If the database role is standby, identification may be performed in the same or substantially similar manner as step 304 in FIG. 4.4. If the database role is standby, identification may be performed in the same or substantially similar manner as step 404 in FIG. 4.4.

[0117] In step 504, it is determined whether the role of the identified database has changed since the backup was performed on the asset group. In one embodiment, when a backup of a database in the asset group is successfully performed, information about the database on which the backup was performed is tracked along with a timestamp indicating when the backup was obtained. This information can be tracked in a data manager record, which can track all backups performed on the databases in the asset group. In addition, the data manager maintains a role history of the databases in the asset group, the role history specifying the current role of each database and at least the timestamp when the database was most recently assigned this role. Therefore, the determination in step 504 may involve comparing the timestamp when the database was most recently assigned this role (TS-R) with the timestamp of the last successful backup (TS-B) of the asset group. If TS-R>TS-B, there has been a role change since the last successful backup. If there has been a role change since the last backup, the method proceeds to step 506; if there has not been a role change since the last backup, the method proceeds to step 508.

[0118] In step 506, it is determined whether the role of the database is currently identified as the primary database of the asset group. If the role is primary, the method proceeds to Figure 3.1 Step 306 in to schedule a full backup of the database with the primary role; if the role is not primary, the method proceeds to Figure 4.1 Step 406 in to schedule a full backup of the database with the standby role.

[0119] If there has been no role change since the last backup, then in step 508, a determination is made as to whether the role of the database is currently identified as the primary database for the asset group. If the role is primary, the method proceeds to Figure 3.1 Step 302 in; if the role is not primary, the method proceeds to Figure 4.1 Step 402 in .

[0120] Example

[0121] Described below Figure 5 Non-limiting examples of the methods shown in .

[0122] Consider a scenario where an asset group includes two databases – Database A and Database B. Furthermore, assume that the backup policy of the asset group specifies that backups be performed on the database with the primary role as follows: (i) a full backup is obtained every Sunday, and (ii) an incremental backup is obtained every 24 hours Monday through Saturday.

[0123] On Sunday, a full backup is performed on Database A because Database A has the primary role. On Monday, an incremental backup is performed on Database A because Database A has the primary role. On Tuesday, Database B assumes the primary role, and because there is a role change, a full backup is performed on Database B (as opposed to a specific asset). On Wednesday, an incremental backup is performed on Database B because Database B has the primary role. On Thursday, Database A assumes the primary role again, and because there is a role change, a full backup is performed on Database A (as opposed to a specific asset).

[0124] if Figure 5 is not implemented, then on Thursday, an incremental backup will be performed relative to the last backup performed on Monday. In this case, the "delta" between the current state of database A (i.e., the state on Thursday) and the last backup of database A (i.e., the incremental backup on Monday). In addition, since the backup of database A is an incremental backup, the backup storage system needs to maintain the following backups of database A - full backup (Sunday), incremental backup (Monday), incremental backup (Thursday) - in order to enable database A to be restored to its state on Thursday.

[0125] In contrast, by implementing Figure 5 According to the method shown in , the system will not need to expend resources to determine the "increment", and the backup storage system will only need to store the full backup (Thursday) instead of the full backup (Sunday), incremental backup (Monday), and incremental backup (Thursday). In addition, once the full backup on Thursday is completed, the backup storage system can delete the full backup (Sunday) and incremental backup (Monday) and any related recovery logs, thereby saving / reclaiming space on the backup storage system.

[0126] End of Example

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

[0128] In one or more embodiments, the one or more computer processors (602) may be integrated circuits for processing instructions. For example, the one or more computer processors may be single-core or multi-core or micro-core processors. The computing device (600) may also include one or more input devices (610), such as a touch screen, keyboard, mouse, microphone, touchpad, electronic pen, or any other type of input device. In addition, the communication interface (612) may include an integrated circuit for connecting the computing device (600) to a network (not shown) (e.g., a local area network (LAN), a wide area network (WAN) (such as the Internet), a mobile network, or any other type of network) and / or another device (such as another computing device).

[0129] In one or more embodiments, the computing device (600) may include one or more output devices (608), such as a screen (e.g., a liquid crystal display (LCD), a plasma display, a touch screen, a cathode ray tube (CRT) monitor, a projector, or other display device), a printer, an external storage device, or any other output device. One or more of the output devices may be the same as or different from one or more input devices. One or more input and output devices may be connected locally or remotely to one or more computer processors (602), non-persistent storage devices (604), and persistent storage devices (606). There are many different types of computing devices, and one or more of the previously mentioned input and output devices may take other forms.

[0130] 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 is broadly applicable to solving a range of problems beyond those discussed herein.

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

[0132] In the above description, numerous details are set forth as examples of the embodiments described herein. Those skilled in the art (who may also 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.

[0133] In the above description of the drawings, any component described with respect to the drawings may be equivalent to one or more similarly named components described with respect to any other drawings in 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.

[0134] Throughout this application, the elements of the drawings may be labeled B to C or D to E. As used herein, the previously mentioned labels mean that the elements may include any number of items, and do not require the elements to include the same number of elements as any other items 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.

[0135] Throughout this application, ordinal numbers (e.g., first, second, third, etc.) may be used as adjectives for elements (i.e., any nouns 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 one element. Rather, 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) a second element in element order.

[0136] As used herein, the phrase "operably connected" or "operably connected" means that there is a direct or indirect connection between elements / components / devices that allows the elements to interact in some manner. For example, the phrase "operably connected" can refer to any direct connection (e.g., a direct wired connection between two devices or components) or indirect connection (e.g., a wired and / or wireless connection between any number of devices or components that connect operably connected devices). Thus, any path that information may pass through can be considered an operational connection.

[0137] Although the embodiments described herein have been 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 conceived without departing 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 backing up a database, the method comprising: receiving a first backup request, wherein the first backup request specifies a role and an asset group identifier for an asset group; Based on the first backup request, identifying a database having the role in the asset group; determining that the role of the database has changed since a last backup of the asset group; as well as In response to the determination, a second backup request for the database is issued, wherein the second backup request is for a full backup. 2 . The method of claim 1 , wherein the first backup request is for a partial backup of the database.

3. The method of claim 1, wherein the last backup of the asset group is a partial backup. The method of claim 1 , wherein the asset group includes a plurality of databases, and the database is one of the plurality of databases.

5. The method of claim 4, wherein the plurality of databases are configured in a high availability configuration.

6. The method of claim 5, wherein the role of the database changes in response to a failover, wherein the role of the database is based on the high availability configuration. The method of claim 5 , wherein the role of the database is primary.

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 backing up a database, the method comprising: receiving a first backup request, wherein the first backup request specifies a role and an asset group identifier for an asset group; Based on the first backup request, identifying a database having the role in the asset group; determining that the role of the database has changed since a last backup of the asset group; as well as In response to the determination, a second backup request for the database is issued, wherein the second backup request is for a full backup.

9. The non-transitory computer-readable medium of claim 8, wherein the first backup request is for a partial backup of the database.

10. The non-transitory computer-readable medium of claim 8, wherein the last backup of the group of assets is a partial backup.

11. The non-transitory computer-readable medium of claim 8, wherein the asset group includes a plurality of databases, the database being one of the plurality of databases.

12. The non-transitory computer-readable medium of claim 11, wherein the plurality of databases are configured in a high availability configuration.

13. The non-transitory computer-readable medium of claim 12, wherein the role of the database changes in response to a failover, wherein the role of the database is based on the high availability configuration.

14. The non-transitory computer-readable medium of claim 12, wherein the role of the database is primary.

15. A system comprising: A data manager, the data manager being configured to: receiving a first backup request, wherein the first backup request specifies a role and an asset group identifier for an asset group; Based on the first backup request, identifying a database having the role in the asset group; determining that the role of the database has changed since a last backup of the asset group; as well as In response to the determination, issuing a second backup request for the database to a proxy service, wherein the second backup request is for a full backup; The proxy service executed on the host is configured to: receiving the second backup request; providing the second backup request to the agent; as well as The agent executed on the host, the agent being configured to: Interact with the database to service the second backup request, wherein servicing the second backup request results in a backup of the database being stored in a backup storage system.

16. The system of claim 15, wherein the first backup request is for a partial backup of the database.

17. The system of claim 15, wherein the last backup of the asset group is a partial backup.

18. The system of claim 15, wherein the asset group includes a plurality of databases, the database being one of the plurality of databases.

19. The system of claim 18, wherein the plurality of databases are configured in a high availability configuration.

20. The system of claim 19, wherein the role of the database changes in response to a failover, wherein the role of the database is based on the high availability configuration.

Images