Abstract:
Systems and methods for backing up clustered databases such that production backups associated with the clustered databases are restorable with near zero downtime. First data indicative of a backup request of a clustered database is transmitted by a first computing device to a second computing device. The first computing device maps the backup staging disks to each of a plurality of nodes. The second computing device adds the mapped staging disks to a backup staging diskgroup on a primary node. The second computing device mounts the backup staging diskgroup to each of the plurality of nodes. The second computing device executes a full backup from at least one of the plurality of nodes to the backup staging diskgroup. The second computing device transmits a catalog of backup information to a database associated with the first computing device. The first computing device creates a snapshot of the first backup staging disk.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority under 35 U.S.C. 119(e) to U.S. Provisional Application No. 62/102,393, entitled “Diskgroup Based Backup,” filed on Jan. 12, 2015, the contents of which is incorporated by reference herein in its entirety. 
     
    
     TECHNICAL FIELD 
       [0002]    This disclosure relates generally to copy data management techniques, and specifically to disk group based backup of databases. 
       BACKGROUND 
       [0003]    Some traditional copy data services provide instant data availability for restore and read write access in certain situations. This instant data availability is realized by mount of filesystem-based backup to a database host. Although traditional protection methods enable instant data accessibility in certain situations, traditional methods are often inadequate, e.g., for the following scenarios: (1) an instant restore of a Very Large Database (VLDB) when a production database goes offline and when a database (e.g., an Oracle database) is protected Out-of-Band (OOB); and (2) provisioning of a clustered database (e.g., Oracle Real Application Clusters (RAC)) in a test and development environment for instant data availability using a production backup of the clustered database. 
       SUMMARY OF THE INVENTION 
       [0004]    In some embodiments, the techniques described herein provide systems and methods of addressing instant restore of a VLDB when a production database goes offline and systems and methods of provisioning a clustered database in a Test &amp; Dev environment using a production backup of a clustered database (also referred to herein as an Oracle RAC database or RAC database) for instant data availability. With the techniques described herein, backing up an out-of-band database can provide Automatic Storage Management (ASM) diskgroup based backup in incremental forever manner. In some embodiments, ASM diskgroup backup is resource efficient with increased throughput with configurable multi-node RAC backup. With the techniques described herein, including ASM diskgroup based backup, copy data storage systems (e.g., Actifio CDS) can provide instant restore of a production database when a disaster strikes by switching a production database to copy data storage where the database backup copy is managed. ASM diskgroup based backup lifecycle management can also provide data migration from copy data storage where the production database is running from after the disaster, back to production storage once it is repaired with zero or near zero downtime. In some embodiments, the systems and methods described herein also enables provisioning of one or more Test &amp; Dev Oracle RAC instance in a near constant time regardless of the size of the database that is being provisioned. 
         [0005]    In some embodiments, systems and methods are described herein for backing up clustered databases such that production backups associated with the clustered databases are restorable with near zero downtime. In some embodiments, the systems and methods described herein include transmitting, by a first computing device, first data indicative of a first backup request of a clustered database to a second computing device at a first point in time, the clustered database associated with an application, the clustered database including a plurality of nodes, each of the plurality of nodes including database data from a shared storage associated with the clustered database. In some embodiments, the systems and methods described herein include mapping, by the first computing device, first backup staging disks to each of the plurality of nodes. In some embodiments, the systems and methods described herein include adding, by the second computing device, the mapped first backup staging disks to a first backup staging diskgroup on a primary node of the plurality of nodes. In some embodiments, the systems and methods described herein include mounting, by the second computing device, the first backup staging diskgroup to each of the plurality of nodes. In some embodiments, the systems and methods described herein include executing, by the second computing device, one of a full backup from the primary node to the first backup staging diskgroup when load balancing is not configured, and a full backup from the primary node and at least one of the other plurality of nodes to the first backup staging diskgroup when load balancing is configured such that the full backup is representative of shared storage data at the first point in time. In some embodiments, the systems and methods described herein include transmitting, by the second computing device, a catalog of first backup information to a database associated with the first computing device. In some embodiments, the systems and methods described herein include creating, by the first computing device, a first snapshot of the first backup staging disk. 
         [0006]    In some embodiments, the systems and methods described herein include transmitting, by the first computing device, second data indicative of a second backup request of the clustered database to a second computing device at a second point in time, and when a second backup request size of the application is larger than a first backup request size of the application, the second backup request size associated with the second backup request and the first backup request size associated with the first backup request: adding, by the first computing device, additional staging disks to the first backup staging disks to form second backup staging disks to account for an expansion of size associated with the application, mapping, by the first computing device, the second backup staging disks to each of the plurality of nodes; adding, by the second computing device, the additional staging disks to the first backup staging diskgroup to form a second backup staging diskgroup, mounting, by the second computing device, the second backup staging diskgroup to each of the plurality of nodes, executing, by the second computing device, incremental backup from each of the other plurality of nodes to the second backup staging diskgroup such that the incremental backup is representative of shared storage data at the second point in time, the incremental backup including backup of difference data, the difference data associated with changes to the application data between the first point in time and the second point in time, transmitting, by the second computing device, a catalog of second backup information to the database associated with the first computing device, and creating, by the first computing device, a second snapshot of the second backup staging disk. 
         [0007]    In some embodiments, the systems and methods described herein include restoring the shared storage data when the shared storage is corrupted, wherein restoring the shared storage data comprises receiving, by the first computing device, third data associated with a request for restoring the shared storage data associated with at least one of the first snapshot and the second snapshot; mapping, by the first computing device, the requested snapshots to the plurality of nodes; mounting, by the second computing device, an associated staging diskgroup to the plurality of nodes; switching, by the second computing device, the clustered database to run from the associated staging diskgroup; and migrating, by the second computing device, associated staging diskgroup data to the shared storage using rebalancing after shared storage is repaired, wherein rebalancing includes spreading the staging diskgroup data evenly across all disks in a diskgroup associated with the repaired shared storage. 
         [0008]    In some embodiments, the systems and methods described herein include provisioning the clustered database for test and development, wherein provisioning the clustered database for test and development comprises: receiving, by the first computing device, fourth data associated with a request for provisioning a portion of the clustered database for test and development, the request including a diskgroup name associated with the portion of the provisioned portion of the clustered database; receiving, by the first computing device, an IP address associated with a plurality of test and development nodes; mapping, by the first computing device, at least one snapshot associated with the requested portion of the clustered database to the plurality of test and development nodes; adding, by a third computing device, the mapped at least one snapshot to a test and development diskgroup associated with the plurality of test and development nodes; updating, by the third computing device, header information associated with disks in the test and development diskgroup with the diskgroup name; mounting, by the third computing device, the test and development diskgroup to each of the plurality of test and development nodes; and executing, by the third computing device, a clone operation from a primary node of the plurality of test and development nodes, wherein executing the clone operation includes creating new parameter files, setting new cluster database names, and communicating with other test and development nodes. 
         [0009]    In some embodiments, the systems and methods described herein include enabling, by a database server, a listener associated with the provisioned clustered database such that the provisioned clustered database is active, the listener managing requests from a client to the clustered database. 
         [0010]    These and other capabilities of the disclosed subject matter will be more fully understood after a review of the following figures, detailed description, and claims. It is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. 
     
    
     
       BRIEF DESCRIPTION OF FIGURES 
         [0011]    Various objectives, features, and advantages of the disclosed subject matter can be more fully appreciated with reference to the following detailed description of the disclosed subject matter when considered in connection with the following drawings, in which like reference numerals identify like elements. 
           [0012]      FIG. 1  is a system diagram showing an example of traditional out-of-band protection of a RAC database with a 3-node setup. 
           [0013]      FIG. 2  is a system diagram showing a RAC backup method using an ASM diskgroup managed by a copy data storage system (CDS), according to some embodiments of the present disclosure. 
           [0014]      FIG. 3  is a flowchart for a first full backup of a RAC database managed by a CDS using ASM staging diskgroup as an option, according to some embodiments of the present disclosure. 
           [0015]      FIG. 4  is a flowchart for incremental backup of a RAC database managed by a CDS, according to some embodiments of the present disclosure. 
           [0016]      FIG. 5  is a system diagram showing traditional methods of restore of a RAC database from backup. 
           [0017]      FIG. 6  is a system diagram illustrating a traditional method of restore of a RAC database with minimum database downtime, but with increased operational complexity. 
           [0018]      FIG. 7  is a system diagram illustrating a restore method with an ASM staging disk based backup with instant restore and no downtime data migration, according to some embodiments of the present disclosure. 
           [0019]      FIG. 8  is a flowchart showing the restoration of a RAC database using ASM backup, according to some embodiments of the present disclosure. 
           [0020]      FIG. 9  is a system diagram showing a provisioning of a test and development RAC database (2-node) from backup. 
           [0021]      FIG. 10  is a system diagram showing a provisioning of a test and development RAC database (2-node) from an ASM backup, according to some embodiments of the present disclosure. 
           [0022]      FIG. 11  is a flowchart showing a process of provisioning a test and development RAC database using ASM diskgroup based backup, according to some embodiments of the present disclosure. 
       
    
    
     DETAILED DESCRIPTION 
       [0023]    In the following description, numerous specific details are set forth regarding the systems and methods of the disclosed subject matter and the environment in which such systems and methods may operate, etc., in order to provide a thorough understanding of the disclosed subject matter. It will be apparent to one skilled in the art, however, that the disclosed subject matter may be practiced without such specific details, and that certain features, which are well known in the art, are not described in detail in order to avoid unnecessary complication of the disclosed subject matter. In addition, it will be understood that the embodiments provided below are exemplary, and that it is contemplated that there are other systems and methods that are within the scope of the disclosed subject matter. 
         [0024]    In some examples, database OOB protection can be performed in a CDS using a native filesystem regardless of whether the source database is running from a filesystem or a disk group (also referred to herein as ASM diskgroup). When restoring an OOB protected instance, the CDS mounts a backup image, followed by RMAN (Recovery Manager) performing a catalog and restore. For a VLDB, restoring the whole database can take a long time, as RMAN physically moves data from a backup image to production storage. An alternative that can be used to minimize the downtime can be achieved by using a mount of a backup image from CDS, and followed by a clone process to standup a database. This methodology can bring an instance up quickly, but running in degraded mode, e.g. if source database is a RAC running from ASM, the cloned instance can only run as standalone instance, and from a filesystem (as backup image copies are stored on a filesystem). Traditionally, a backup destination is either filesystem or tape. Cloning of a source database also presents similar challenges in an RAC environment where test and development is also required to run the exact same deployment configuration as source. 
         [0025]    In some embodiments, systems and methods described herein use an ASM diskgroup as a backup staging disk format, the CDS uses RMAN to backup database as image copy to the CDS staging disk; upon the completion of the backup, the CDS takes a snapshot of the staging disk to create a point in time copy of the backup. With an ASM diskgroup based backup, the CDS can restore a production database by using an RMAN switch to a managed database backup copy. 
         [0026]      FIG. 1  is a system diagram showing an example of traditional out-of-band protection of a RAC database with 3-node setup. For illustration,  FIG. 1  and some other examples described herein refer to Oracle-based systems, components and/or databases. However, such reference to Oracle-based systems is exemplary only, and it should be understood that any other database systems, components and databases can be used without departing from the spirit of the techniques described herein. Oracle RAC database  1020  includes RAC node  1001 , RAC node  1002 , and RAC node  1003 . In some embodiments, a RAC node refers to a member host of Oracle Real Application Clusters, where there are one or more hosts making up the cluster. Oracle RAC instances  1004 ,  1005  and  1006  runs on their respective hosting nodes. A RAC instance refers to a database instance which is a member of the Oracle Real Application Clusters. Oracle RAC nodes  1001 ,  1002 , and  1003 , use ASM RAC shared storage  1007 . Connector  1008  (e.g., Actifio Connector) is installed on RAC node  1001  and communicate with CDS  1011 . Connector is a program running on each member node to facilitate communications between CDS and member node and to perform tasks (e.g., mapping disks onto a node) on the member node. Staging filesystem  1010  is created by connector  1008  for RMAN Backup  1009 . RMAN backup  1009  refers generally to a backup process by a database client that performs backup, restore, and recovery of database files. CDS  1011  creates staging disks  1012  for Oracle RAC backup. Staging disks  1012  refer to disks made available to the filesystem  1010  for data backup. Staging disks  1012  are mapped to a single node (e.g., RAC node  1001 ) only. After RMAN Backup  1009  completes, CDS  1011  creates FlashCopy  1013  from staging disks  1012 . FlashCopy  1013  refers generally to a point-in-time snapshot copy of a data set or volume. FlashCopy  1013  is further processed into Dedup storage  1014 . Dedup storage  1014  refers generally to storage of deduplicated data. 
         [0027]    CDS  1011  and Connector  1008  are responsible for backing up Oracle RAC database  1020 , which resides on ASM RAC Shared Storage  1007  and is backed up onto the Staging filesystem  1010 . CDS  1011  catalogs each of the backup details and corresponding FlashCopy  1013 , which can be used for restore and Test &amp; Dev operations at a user&#39;s discretion, as described in more detail in U.S. application Ser. No. 14/546,757, entitled “Test-and-Development Workflow Automation,” filed Nov. 18, 2014, the contents of which are herein incorporated in their entirety. 
         [0028]      FIG. 2  is a system diagram showing a RAC backup method using an ASM diskgroup managed by a copy data storage system (CDS), according to some embodiments of the present disclosure. 
         [0029]    CDS  1011  and Oracle RAC database  1020  under protection is the same as those described in  FIG. 1 . CDS  1011  creates staging disks  1012  and maps them to all three RAC nodes  1001 ,  1002 , and  1003 . CDS  1011  initiates backup requests to Connector  2001 . Connector  2001  adds the mapped staging disks to staging ASM diskgroup  2004  and mounts the staging diskgroup  2004  to a database instance  1004   1005   1006  on the RAC nodes  1001   1002   1003 . A backup stream can be configured from multiple RAC nodes as staging ASM diskgroup  2004  is mounted on all RAC nodes. For example, a backup stream can contain data from any one of the DB instances  1004   1005   1006 . As discussed above, each of the DB instances  1004   1005   1006  are instances of portions of data within ASM RAC shared storage  1007 . Connector  2001  controls the RMAN backup  2005 , as well as RMAN backup  2006  and  2007 . Connector  2002  and  2003  process mapped disks on RAC node  1002  and  1003  when multiple nodes are configured to participating in the backup. Once the RMAN backup completes for Oracle RAC, Connector  2001  sends a message with backup details to CDS  1011 . CDS  1011  then creates a FlashCopy  1013  and updates its management database on CDS  1011  for this backup. A management database is a persistent datastore on CDS  1011  where all backup information is stored. FlashCopy  1013  is further processed into Dedup storage  1014 . Dedup storage  1014  refers generally to storage of deduplicated data. 
         [0030]      FIG. 3  is a flowchart for a first full backup of a RAC database managed by a CDS using ASM staging diskgroup as an option, according to some embodiments of the present disclosure. 
         [0031]    In some embodiments, a CDS user interface can provide an ASM Diskgroup  2004  as a staging disk option for an Oracle backup configuration. A user can select to use an ASM Diskgroup  2004  as a staging disk for an Oracle database backup. At step  3001 , CDS  1011  checks whether ASM diskgroup  2004  is selected as a staging disk option. When this option is not selected, the backup moves to Step  3002 , where CDS  1011  creates staging disks and maps them to the primary backup RAC node  1001 . Referring to step  3003 , Connector  1008  creates a staging filesystem  1010  and mounts it on the primary backup RAC node  1001 . Referring to step  3004 , Connector  1008  performs a full Oracle database backup using RMAN image copy  1009 . Connector  1008  unmounts the staging filesystem at the conclusion of the RMAN backup  1009  and sends a message to CDS  1011 . Referring to step  3005 , CDS  1011  catalogs backup information of the Oracle RAC database in its management database. 
         [0032]    Referring to step  3001 , when using ASM diskgroup as staging option is selected, CDS  1011 , at step  3006  checks whether an Oracle database is running on ASM. If it is not, CDS  1011  fails the backup in Step  3007 . When Oracle database running on ASM diskgroup  2004  is verified at step  3008 , CDS  1011  creates staging disks and maps them to all RAC nodes  1001   1002   1003 . Referring to step  3009 , Connector  2001  creates staging ASM diskgroup  2004  on the primary backup node  1001  with all staging disks mapped from step  3008 . Referring to step  3010 , Connectors  2001   2002   2003  mount ASM staging diskgroup  2004  on all Oracle RAC nodes  1001   1002   1003 . Referring to step  3011 , Connector  2001  performs a full backup from the primary backup RAC node  1001 . RMAN backup  2005   2006   2007  can be running on multiple RAC nodes using load balancing when load balancing is configured. Load balancing for backup is multiple-nodes sharing the backup loads when there are more than one node is configured for the backup activity. At the conclusion of the RMAN backup, Connector  2001  sends a message to CDS to indicate either a successful backup or failure. Connector  2001  is the primary facilitator between CDS and Oracle RMAN to conduct the backup. Connector  2002  and  2003  are responsible to prepare mapped staging disks on RAC node  1002  and  1003  so that staging diskgroup will be available on all 3 RAC nodes when Connector  2001  creates and mounts the staging diskgroup. This can be performed when load balancing for the backup becomes available and is managed by the manager of the database (e.g., an Oracle database manager). Referring to step  3012 , CDS  1011  catalogs the backup information of the Oracle RAC database in CDS management database. 
         [0033]      FIG. 4  is a flowchart for incremental backup of a RAC database managed by a CDS, according to some embodiments of the present disclosure. 
         [0034]    Referring to step  4001 , CDS  1011  checks whether ASM diskgroup  2004  is selected as a staging disk option. If this option is not selected, at step  4002 , CDS  1011  checks whether source Oracle RAC database  1020  has expanded its size, and adds more staging disks if database size increases. At step  4003 , CDS  1011  maps staging disks to primary RAC backup node  1001  if these disks are not already mapped. Step  4004 , Connector  1008  expands staging filesystem if there are new staging disks added due to source Oracle RAC database size increase. Step  4005 , Actifio Connector mounts the staging filesystem and performs an incremental RMAN backup. At the conclusion of the backup, Actifio Connector sends message with backup details to Actifio CDS to complete the backup. Step  4006 , Actifio CDS catalogs the backup information in CDS management database. 
         [0035]    When CDS  1011  detects using ASM diskgroup as a staging disk option is selected at step  4001 , CDS  1011  checks whether protected Oracle database  1020  is running on an ASM instance at step  4007 . Referring to step  4008 , CDS  1011  fails the backup if the Oracle database is not running on ASM. Referring to step  4009 , CDS  1011  adds more staging disks if source Oracle RAC database  1020  has grown in size. This procedure can ensure that the backup will be incremental even when the source database grows in size. Referring to step  4010 , CDS  1011  maps staging disks to all Oracle RAC nodes  1001   1002   1003  if not already mapped. Referring to step  4011 , Connector  2001  adds any new staging disks to backup staging ASM diskgroup on primary RAC backup node  1001 . Referring to step  4012 , Connector  2001  mounts staging ASM diskgroup on all Oracle RAC nodes  1001   1002   1003  after Connector  2002  and  2003  prepares mapped staging disks on RAC nodes  1002  and  1003  if they are not already mounted. Referring to step  4013 , Connector  2001  starts RMAN incremental backup  2005   2006   2007  from all backup RAC nodes using load balancing if the feature is configured. Connector  2001  sends message with backup information to CDS  1011  at the conclusion of the backup. Referring to step  4014 , CDS  1011  catalogs backup information in CDS management database. 
         [0036]      FIG. 5  is a system diagram showing traditional methods of restore of a RAC database from backup. 
         [0037]    When Oracle RAC database  1020  encounters a storage array issue, for example one of the ASM disks becomes corrupt in ASM RAC Shared Storage  1007 , a user can use CDS  1011  to select a restore point from FlashCopy  1013 . CDS  1011  creates a FlashCopy of this backup  5001 , and maps the disks to RAC node  1001 . Connector  1008  mounts the filesystem from the mapped backup disks  5002 . Once backup is mounted, RMAN Restore  5003  can use it to restore database, tablespace(s), or datafile(s) to ASM RAC Shared storage  1007 . Although CDS  1011  can mount the backup image instantly, this process involves database downtime to allow the RMAN Restore  5003  to complete. 
         [0038]      FIG. 6  is a system diagram illustrating a traditional method of restore of a RAC database with minimum database downtime, but with increased operational complexity. This method requires a standby server  6001 , and multiple phases for restore and data migration back to production storage. 
         [0039]    When Oracle RAC database encounters a storage array issue, it can lead to failure of a production diskgroup(s). To minimize the database downtime, a user selects a restore point from backup image from CDS  1011 , and uses FlashCopy  1013  to create a FlashCopy of backup  6004 . CDS  1011  maps disks from FlashCopy of backup  6004  to the standby Server  6001 . Connector  6002  mounts the backup filesystem to Standby Server  6001 . Connector  6002  starts a clone operation to clone Oracle DB instance  6003 . Once clone operation completes, Oracle DB instance  6003  receives connections from application layer and serving requests, and consequently, database service is restored. 
         [0040]    In order to migrate new transactional data received by newly cloned database back to production storage, Oracle DB instance  6003  is protected by CDS  1011 . Both DB Staging filesystem  6004  and Log Staging filesystem  6005  are protected in band. Oracle DB instance  6003  will be protected by CDS in shorter intervals for both database datafiles  6004  and its archivelogs  6005 . 
         [0041]    Once ASM RAC Shared Storage  1007  is repaired, datafiles from Oracle DB instance  6003  can be restored back to production ASM RAC Shared Storage  1007 . CDS  1011  creates Flashcopy of backup FlashCopy  6008  and maps disks to RAC Node  1001 . Connector  1008  mounts the backup filesystem  6005  to RAC Node  1001 . RMAN Restore  6010  restores database first and leaves the database in a mounted state. Connector  1008  mounts archivelog filesystem to RAC Node  1001  to allow RMAN to apply archivelogs  6011 . Connector  1008  repeats the application of archivelogs after a new archivelog backup becomes available from the cloned Oracle DB instance  6003  of Standby Server  6001 . Connector  1008  then schedules a maintenance window for downtime, shuts down cloned Oracle DB instance  6003 , and takes the last archivelog backup and applies the last backup to Oracle DB Instance  1004  on RAC Node  1001 . The Oracle RAC database with all data migrated from cloned Oracle DB instance  6003  can now be opened. 
         [0042]      FIG. 7  is a system diagram illustrating a restore method with an ASM staging disk based backup with instant restore and no downtime data migration, according to some embodiments of the present disclosure. 
         [0043]    Once ASM RAC Shared Storage  1007  encounters storage issues and Oracle RAC database is down, CDS  1011  creates FlashCopy from backup FlashCopy  1013 . CDS  1011  maps disks to RAC Nodes  1001 ,  1002 ,  1003 . Connector  2001  mounts ASM backup diskgroup  7001  to RAC node  1001 . Connector  1001  issues RMAN switch  7002  and Oracle RAC database  1020  is running from ASM backup diskgroup  7001 . All new writes can go to ASM backup diskgroup  7001 . After ASM RAC Shared Storage  1007  is repaired, RMAN Rebalance  7003  can migrate data from ASM backup disks  7001  to ASM RAC Shared Storage  1007 . User can remove ASM diskgroup disks  7001  after rebalance completes and all data is migrated onto ASM RAC Shared Storage  1007 . In some embodiments, ASM attempts to spread the data evenly across all disks in a diskgroup. When a disk is added or removed from a diskgroup, ASM can re-spread all data files across the new disk layout, which is referred to herein as rebalance. 
         [0044]      FIG. 8  is a flowchart showing the restoration of a RAC database using ASM backup, according to some embodiments of the present disclosure. 
         [0045]    At step  8001 , a user selects an ASM backup image on CDS  1011  for restore. At step  8002  CDS  1011  prompts user for a preferred Diskgroup name to be used for restore. At step  8003  CDS maps ASM backup flashcopy disks to all RAC nodes  1001   1002   1003 . At step  8004  Connector  2001  mounts ASM diskgroup on all RAC nodes  1001   1002   1003 . If mounting diskgroup fails  8005 , at step  8013 , Connector  2001  unmaps ASM flashcopy from RAC nodes  1001   1002   1003 . At step  8014 , CDS  1011  updates the management database. 
         [0046]    If mount ASM diskgroup is successful  8005 , Connector  2001 , at step  8006 , issues RMAN Switch to switch production database to ASM diskgroup mounted by CDS  1011 . A lock file for managing RMAN lifecycle is created on all RAC nodes  8007 . The lock file is a file with attributes denoting the database name in the switch process and status of the switch process. Once the Oracle ASM production storage issue is resolved, the production disks are repaired at step  8008  by adding production disks to a restore diskgroup. At step  8009 , data migration is started from ASM backup disks to production disks using rebalance and ASM backup disks are dropped from the restore diskgroup. In some embodiments, dropping a disk from a diskgroup refers to removing a disk from the diskgroup. In some embodiments, the removal of the disk does not take place until after rebalancing is complete. At step  8010  rebalance status is updated in lock file on all nodes to allow cleanup of ASM disks. At step  8011 , users can unmount and delete ASM backup disks from all RAC nodes and from CDS. At step  8012 , Oracle RAC database is fully restored back to production storage. 
         [0047]      FIG. 9  is a system diagram showing a provisioning of a test and development RAC database (2-node) from backup. When Test &amp; Development requires Oracle RAC setup, the existing method is to use RMAN restore to an ASM diskgroup, which takes up the same amount of storage footprint as in production and can be expected to take time linearly proportional to the production backup size. 
         [0048]    CDS  1011  backs up Production RAC database Node  9001   9002  onto Staging filesystem  9009 , backup images created as FlashCopy  1013 . When a Test &amp; Development provision requests comes, CDS  1011  creates Flashcopy of Oracle backup  9018  from FlashCopy  1013 . The disks from Flashcopy of Oracle backup  9018  are mapped to Test RAC Node  9011 . Connector  9014  mounts the backup filesystem to Test RAC Node  9011 . RMAN Restore to ASM diskgroup  9019  restores Oracle backup to ASM RAC Shared Storage  9016 . Test Oracle DB Instance  9015  can be opened for READ and WRITE for testing. 
         [0049]      FIG. 10  is a system diagram showing a provisioning of a test and development RAC database (2-node) from an ASM backup, according to some embodiments of the present disclosure. The systems and methods described herein can provision a multi-node RAC that requires a near zero storage footprint and take near constant time regardless of the size of the production backup. 
         [0050]    CDS  1011  backs up Oracle RAC database from RAC Node  10001  and  10002  using ASM diskgroup as the staging disk. To provision a 2-node RAC database in Test &amp; Dev, CDS creates disks  10019  from FlashCopy  1013  and maps them to Test RAC Node  10011  and Test RAC Node  10012 . Connector  10013  adds mapped ASM backup disks  10019  to an ASM restore diskgroup  10020  and mounts the diskgroup to ASM instance (not shown) running on Test RAC node  10011  and  10012 . In some embodiments, an ASM instance is required to run on all RAC nodes in order for the RAC to function. In some embodiments, an ASM instance is a small and lightweight database instance that manages disks in a disk group and controls administrative tasks for the disk group (e.g., an Oracle instance that manages the disks in the ASM diskgroups and administrative works related to ASM). Connector  10013  starts clone operation using ASM Restore diskgroup  10020 . Once the clone operation completes, an Oracle RAC database with 2 instances Oracle DB instance  10014  on Test RAC Node  10011  and Oracle DB instance  10016  on Test RAC Node  10012  opens in READ/WRITE mode. As there is no data movement in this managed Oracle RAC clone process, the time required to finish the clone is near constant and storage footprint is near zero. 
         [0051]      FIG. 11  is a flowchart showing a process of provisioning a test and development RAC database using ASM diskgroup based backup, according to some embodiments of the present disclosure. 
         [0052]    At step  11001 , a user selects an ASM backup image on CDS for Test and Dev instance provisioning. At step  11002 , a CDS user interface provides an option for a user to enter IP addresses of member nodes where RAC instances will be running from. 
         [0053]    At step  11003 , CDS maps disks off backup flashcopy to all RAC member nodes. 
         [0054]    Step  11004 , Connector updates header of backup ASM disks with new diskgroup name, creates the new diskgroup with modified backup ASM disks and mounts the diskgroup on all RAC member nodes. 
         [0055]    Step  11005 , CDS checks the mount status of the new ASM diskgroup. If mount fails, at step  11006 , mapped disks from all nodes are cleaned up and unmapped from CDS. At step  11007 , CDS updates management database. 
         [0056]    If mount is successful in step  11005 , at step  11008 , Connector starts provision clone operation from primary RAC node, creating new parameter files, set new RAC database name, communicate with other member node(s) for RAC database clone. The communication with other member nodes includes setting up parameter file for RAC instance and required directory structures. At step  11009 , Connector setups remote listener and scan listener, and open RAC database. The listener is a separate process that runs on the database server. It receives incoming client connection requests and manages the traffic of these requests to the database. At step  11010 , Test &amp; Dev RAC database is in use, serving requests from the application layer. At step  11011 , user can use Test &amp; Dev lifecycle management, which is provided by CDS, and check whether it is time to tear down the RAC database. CDS Test &amp; Dev lifecycle management allows creation of a database instance for Test &amp; Dev use and teardown the database and cleanup all its resources. At step  11012 , Connector tears down the Test &amp; Dev database by shutting down a provisioned RAC database. At step  11013 , Connector cleanups artifacts generated as a result of provisioned RAC database. At step  11014 , Connector unmounts and drops ASM diskgroup, cleanup CRS (Oracle Cluster Ready Services) resource. At step  11006 , CDS cleanups mapped ASM disks from all nodes and unmaps from CDS. At step  11007 , CDS updates management database. 
         [0057]    In some examples described herein, the techniques are described with respect to Oracle databases and systems. These examples are intended to be exemplary only and not limiting. The techniques described herein can be implemented with other types of storage methods and systems, as can be appreciated by one of skill in the art. For example, the systems and methods described herein can also apply to other databases and systems with similar functionality as ASM. ASM (Automatic Storage Management) is a management tool designed by Oracle specifically for Oracle database storage management. ASM provides a consistent storage management interface across all server and storage platforms. ASM also provides a clustered filesystem for RAC databases and a consistent clusterwide namespace for database files. ASM simplifies administration of Oracle related files by managing a group of disks rather than individual disks and files. The main components of ASM are disk groups, each of which comprise of several physical disks that are controlled as a single unit. The physical disks are known as ASM disks; while the files that reside on the disks are know as ASM files. The locations and names for the files are controlled by ASM, but user-friendly aliases and directory structures can be defined for ease of reference. 
         [0058]    In some examples described herein, the techniques are described with respect to systems provided by Actifio. These examples are intended to be exemplary only and not limiting. The systems and methods described herein can utilize any other type of system, as can be understood by a person of skill in the art. For example, Actifio CDS, as used herein, can be protecting a production database with this technique, and provide instant restore capability for the protected database. Actifio CDS, when using this technique, can also provides instant provisioning capability for test &amp; dev equivalent of production database setup. Actifio CDS keeps point-in-time flashcopy backup images which can be used to restore or provision test &amp; dev instances. The metadata of flashcopy backup image is maintained in a management database that is updated after each backup. Actifio CDS manages life cycle of backup of databases and test &amp; dev copies originated from the backups. 
         [0059]    The subject matter described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them. The subject matter described herein can be implemented as one or more computer program products, such as one or more computer programs tangibly embodied in an information carrier (e.g., in a machine readable storage device), or embodied in a propagated signal, for execution by, or to control the operation of, data processing apparatus (e.g., a programmable processor, a computer, or multiple computers). A computer program (also known as a program, software, software application, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file. A program can be stored in a portion of a file that holds other programs or data, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. 
         [0060]    The processes and logic flows described in this specification, including the method steps of the subject matter described herein, can be performed by one or more programmable processors executing one or more computer programs to perform functions of the subject matter described herein by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus of the subject matter described herein can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). 
         [0061]    Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processor of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of nonvolatile memory, including by way of example semiconductor memory devices, (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks, (e.g., internal hard disks or removable disks); magneto optical disks; and optical disks (e.g., CD and DVD disks). The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry. 
         [0062]    To provide for interaction with a user, the subject matter described herein can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, (e.g., a mouse or a trackball), by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well. For example, feedback provided to the user can be any form of sensory feedback, (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user can be received in any form, including acoustic, speech, or tactile input. 
         [0063]    The subject matter described herein can be implemented in a computing system that includes a back end component (e.g., a data server), a middleware component (e.g., an application server), or a front end component (e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described herein), or any combination of such back end, middleware, and front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet. 
         [0064]    It is to be understood that the disclosed subject matter is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. The disclosed subject matter is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. 
         [0065]    As such, those skilled in the art will appreciate that the conception, upon which this disclosure is based, may readily be utilized as a basis for the designing of other structures, methods, and systems for carrying out the several purposes of the disclosed subject matter. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the disclosed subject matter. 
         [0066]    Although the disclosed subject matter has been described and illustrated in the foregoing exemplary embodiments, it is understood that the present disclosure has been made only by way of example, and that numerous changes in the details of implementation of the disclosed subject matter may be made without departing from the spirit and scope of the disclosed subject matter, which is limited only by the claims which follow.