Patent Publication Number: US-7584339-B1

Title: Remote backup and restore operations for ISB protocol systems

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
   This application is related to co-pending U.S. patent application Ser. No. 11/536,130, filed Sep. 28, 2006, co-pending U.S. patent application Ser. No. 11/536,157, filed Sep. 28, 2006, and co-pending U.S. patent application Ser. No. 11/536,141, filed Sep. 28, 2006. All of these applications are incorporated by reference herein in their entireties. 
   BACKGROUND OF THE INVENTION 
   1. The Field of the Invention 
   The present invention relates to systems and methods for backing up and restoring data. More particularly, embodiments of the invention relate to systems and methods for performing replication operations using ISB protocol systems. 
   2. The Relevant Technology 
   In this society where many personal and business interactions are data driven, data can become easily lost or corrupted due to events such as system failures, viruses, power outages, etc. Backing up data has become an important feature of computer networks because of this increasing dependence upon computers and networks to perform vital business and personal functions. The ability to easily, accurately and reliably access data is expected by anyone accessing a computer and/or network. 
   Backup and recovery of data is typically accomplished through the use of software that creates a backup copy of data and that recovers the data from the backup copy. As the amount of data continues to increase, and as the applications for creating data become more complex, backing up and recovering the data becomes more challenging. It would be advantageous to be able to restore the data at optimal points in time so that full recovery of all of the desired data is achieved without corrupting other data or processes on a computer. In particular, in the health care information system industry, the MAGIC platform, which operates using Integrated Serverless Backup (ISB) protocol, both of which are provided by MEDITECH, allows health care providers to perform basic backups of data. However, it would be advantageous to provide administrators of these health care systems with the ability to perform scheduled backups, recover data at particular points in time, as well as perform other replication operations and recovery operations on saved data. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     To further clarify the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which: 
       FIG. 1A  illustrates an example of a system for performing replication operations using ISB protocol in accordance with one embodiment of the present invention. 
       FIG. 1B  illustrates another example of a system for performing replication operations using ISB protocol in accordance with one embodiment of the present invention. 
       FIG. 2  illustrates an example of system and software architecture for performing replication operations using ISB protocol in accordance with one embodiment of the present invention. 
       FIG. 3  illustrates an example of a method for performing replication operations using ISB protocol in accordance with one embodiment of the present invention. 
       FIG. 4  illustrates an example of a method for backing up a clone volume using ISB protocol in accordance with one embodiment of the present invention. 
       FIG. 5  illustrates an example of a method for creating a snapshot using ISB protocol in accordance with one embodiment of the present invention. 
       FIG. 6  illustrates an example of a system for performing recovery operations using ISB protocol in accordance with one embodiment of the present invention. 
       FIG. 7  illustrates an example of a method for performing recovery operations in accordance with one embodiment of the present invention. 
   

   DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
   In the following detailed description of the various embodiments, reference is made to the accompanying drawings which form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention. 
   The principles of the present invention relate to a system configured for performing backup and restore operations using Integrated Serverless Backup (ISB) protocol to perform replication operations on data generated on a MAGIC platform. Data stored and recovered can be used for backup/recovery operations (e.g., disaster recovery), mirroring functions, data mining, data consistency, as well as other analysis. 
   Exemplary systems include a production application residing on a host computer and a production volume configured for continually storing changes that occur in the production application. Each time data is written by the production application that is being protected, the production volume is triggered and a copy of the data involved in the read/write operation is created and stored on the production volume. The production volume basically performs a continuous series of write operations. The production volume is able to retain information about every change to a selected application, directory, volume, or the like, over a long period of time, and a user can later utilize the production volume to access stored data. Exemplary systems also include mirroring the data in the production volume using a clone volume. The present invention provides for remote backup of data in the clone volume. 
   In addition, the present invention provides for snapshots to be created of the data stored in the production volume or clone volume at various points in time. The snapshots are read-only point-in-time replicas or representations of the original data or contents of one or more volumes. A snapshot can be used to make an actual copy on another local or remote storage device. These snapshots can be recovered at a later time by reading the data for a snapshot created at a particular point in time. Furthermore, numerous snapshots can be saved. Thus, snapshots provide the user with greater control over how data is stored and/or recovered. 
   As used herein, the term “replication operation” covers various processes for creating a copy of a clone volume. One example of a replication operation includes creating a copy of a clone volume and storing the copy in backup storage. Storing a copy of clone volume is also referred to herein as a “backup” of a clone volume. Another example of a replication operation includes creating a copy of a clone volume in the form of a snapshot and storing the snapshot in a storage device. Thus, a snapshot is considered to be a “backup” of a clone volume. Hence, as used herein, the term “backup” will be used to refer to both storing a copy of a clone volume in backup storage as well as creating a snapshot from a clone volume. 
   Backup clone volumes and/or snapshots are beneficial, for example, to facilitate data recovery after the occurrence of a disaster. A disaster includes any event in which data is lost or corrupted in any way, or when an operating system or other application is corrupted or damaged in any way that requires the operating system or application to be repaired or reinstalled. Data can be lost, damaged or corrupted in any number of ways, including a system crash, burglary, virus, human error, damage to the system, and the like. A backup clone volume and/or snapshot is stored on a backup storage medium, such as an optical disk, hard disk, floppy disk, tape, or any other storage medium that is physically stored in a location separate from the production volume and accessed to recover the data after the production volume experiences a disaster. 
   As used herein, the term “data” may include, but is not limited to, directories (e.g., volumes, file systems, and the like), user data, system data, applications, services, operating systems, and the like, that can be stored on one or more storage devices of a computer. Backing up or recovering the operating system may include backing up or recovering any of the data herein defined or understood by those of skill in the art. Data may be organized in logical directories that do not necessarily correspond to a particular storage device. The term “directory” can be used to refer to any means of logically organizing data on a computer. 
   Even though data may exist on many different storage devices, data can be organized into logical directories and subdirectories so that a user can easily locate information. In one example, in Windows® operating system, the main directories are referred to as volumes. Volumes include, for example, the C drive and D drive, which are typical volumes of storage that are located on a computer, even though the C or D drive itself may comprise a collection of hard disks or a portion thereof. It is not necessary for a user to know from which particular disk to obtain information. Thus, directories exist to help a user navigate through the data on the computer. Other directories may exist to which the computer has access through a network. 
   For purposes of simplicity, the term “production application” will often be used herein to describe the source of data that is being backed up. As will be described below, complex software applications benefit from the backup and restore technology disclosed herein because the data related to applications are typically subject to constant alteration. The technology disclosed herein facilitates the backup and recovery of all types of data and/or data structures, and can be particularly beneficial to applications whose data is continually changing. Although certain embodiments described herein will often refer to the backup of production applications, the technology described herein applies equally to the backup and recovery of all types of data, including directories, volumes, file systems, servers, user data, system data, services, operating systems, and the like. 
   Certain embodiments described herein will involve electronic communication between a client computer system (hereinafter referred to as a “client”) requesting access to a network service at a server computer system (hereinafter referred to as a “server”). Accordingly, the client sends a request to the server for particular access to its system resources, wherein if the client is authorized and validated, the server responds with a response message providing the desired information. Of course, other messaging patterns between client and server are available, as is well known in the art. 
   As used herein, the term “user” may refer to a person operating the server (e.g., administrator). Alternatively, the term “user” may refer to a person at a client or management console. Users are able to initiate a request for mirroring, backup and/or restore, although it will be appreciated that the server may have additional functionalities not available to the client or management console. 
   Exemplary System for Performing Backup/Restore Functions Using ISB Protocol 
     FIG. 1A  illustrates an exemplary system  100 A for performing remote backup/recovery functions using ISB protocol systems.  FIG. 1A  depicts a plurality of host  7  computers  102 A,  102 B,  102 C that, in one embodiment, are networked together. As used herein, the term “networking” refers to spreading applications across multiple host computers  102 A,  102 B,  102 C based on performance requirements where additional host computers are used to scale and meet performance requirements. A group of host computers  102 A,  102 B,  102 C with related applications or business unit functions is referred to as a group or network  103 . 
   In  FIG. 1A , host computers  102 A,  102 B,  102 C are communicatively coupled to a primary storage  114  which includes one or more storage devices  115 A,  115 B. Storage device  115 A includes a production volume  116  for storing data generated on a MAGIC platform on one or more of the host computers  102 A,  102 B,  102 C. A clone volume  117  stores a mirror copy of the data of the production volume  116 . 
     FIG. 1A  also depicts host computers  102 A,  102 B,  102 C being communicatively coupled to a proxy host  170  to allow the proxy host  170  to communicate directly with primary storage  114  (see dashed line). Proxy host  170  is, in turn, communicatively coupled to a backup server  152  which sends backup commands to the proxy host  170  to initiate backup of a clone volume  117 . When backing up a clone volume  117 , backup server  152  is communicatively coupled to a backup storage  154  for remotely storing the copy of the clone volume. Proxy host  170  also initiates creation of snapshots  118 , which are data copied from the clone volume  117  at the same or different points in time. In the embodiment of  FIG. 1A , snapshot  118 A was generated at time t 1  while snapshot  118 B was generated at time t 2 , and snapshot  118 C representing other potential snapshots created at various points in time t n . These snapshots  118  can be stored in a different storage device  115 B as shown in  FIGS. 1A and 1B  or can be stored in the same storage device  115 A as production volume  116  and clone volume  117  (not shown). 
   Turning now to  FIG. 1B , features of system  100 A are shown in more detail with reference to system  100 B, wherein like elements will be referred to with like reference numerals. As shown in  FIG. 1B , for purposes of describing the features of host computer  102 , a single host computer  102  is depicted. However, the description relating to host computer  102  applies to any of the host computers  102 A,  102 B,  102 C illustrated in  FIG. 1A . 
   In one embodiment, host computer  102  is an individual computer. In another embodiment, host computer  102  is a server that is in communication with a network of client computers (not shown). In another embodiment, host computer  102  is a client computer that is communicatively coupled to a central server (described below). Host computer  102  is relatively simple (e.g., a desktop computer) or relatively complex (e.g., a large database server, a cluster of servers, or a production server). 
   Host computer  102  includes at least one production application  104 , which contains and generates data that can be stored, mirrored, backed up, recovered, data mined, and the like. By way of example only, production application  104  may include applications such as, but not limited to, patient admissions, medical records, laboratory records, pharmacy records, personnel/payroll records, as well as other health care industry-related applications. However, the present invention is not specific to health care industry-related applications and can extend to other enterprises. 
   Furthermore, as mentioned above, production application  104  may be networked over multiple host computers  102 , volumes, directories, disks, or the like. Conversely, individual production applications  104  may be located on distinct host computers  102  so that a host computer is responsible for only certain production applications. As noted above, the term “production application” is merely used by way of example to further illustrate the present invention, because complex applications whose data is continually being altered benefit from the technology disclosed herein. However, other data on host computer  102  may also undergo storing, mirroring, backing up, data mining, and the like, which data may also include directories, volumes, file systems, servers, and other types of data described previously. 
   The production application  104  operates on a platform known as the MAGIC platform  106 . The MAGIC platform  106  initially evolved from the minicomputer-based MAGIC platform to eventually run on a Windows® platform. The MAGIC platform  106  provides common services to the production application(s)  104  including networking and data storage capabilities that are managed by network management service  108  and database management service  110 , respectively. 
   The database management service  110  organizes the storage of data for production application  104  into primary storage  114 . Thus, the storage devices  115 A,  115 B in primary storage  114  contain data relating to the production application  104  and/or MAGIC platform  106 . Database management service  110  facilitates communication between the host computer  102  and storage device  115 A. Production volume  116  records a copy of all changes made to the data of production application  104 . As production application  104  receives or transmits input/output operations, which is only one example of generating data, the input/output data is recorded by production volume  116 . In one embodiment, the input/output data is sent from production application  104  to production volume  116 . In an alternative embodiment, data is first sent to database management service  110  which relays the input/output data to production volume  116 . 
   In one embodiment, the production volume  116  is organized into segments, each segment comprising a range of blocks containing production application data. Each segment is configured to failover. Other configurations for production volume  116  would be understood to those of skill in the art. 
   In addition, the database management service  110  performs basic data storage functions between host computer  102  and primary storage  114 . The database management service  110  conventionally provided users with a mechanism to request replication of the production volume  116  in primary storage  114  in the form of one or more clone volumes  117 . As shown in  FIG. 1A , the production volume  116  and clone volume  117  are connected while data is being copied from a production volume  116  to clone volume  117  (i.e., a normal state). The foregoing configuration provides the ability to mirror data from the production volume  116  to the clone volume  117 . This configuration provides multiple layers of redundancy where data is lost or corrupted. If the production volume  116  fails, the clone volume  117  is able to restore the data to the same or another production volume  116 . In contrast, as depicted in  FIG. 1B , the connection between a production volume  116  and clone volume  117  is temporarily severed (i.e., a special state) to perform other replication functions. This splitting of the production volume  116  and clone volume  117  between normal state and special state is accomplished using ISB protocol. 
   Primary storage  114  includes an index  120  for recording metadata containing information about the contents of the production volume  116  and clone volume  117 . Each storage array or device  115  must be aware of any relationship that it is maintained between a production volume  116  and a clone volume  117 , and the index  120  provides a mechanism whereby a user can query that relationship. As shown in  FIGS. 1A and 1B , primary storage  114  can be connected to a single or multiple host computers  102  as well as other servers used for other purposes. 
   In  FIGS. 1A and 1B , primary storage  114  is depicted as a storage area network (SAN). For example, primary storage  114  is a CLARiiON storage cluster comprising one or more storage devices  115 A,  115 B, each of which may or may not be located at the same location, and may or may not be located at different locations and networked together. The CLARiiON environment permits SAN Copy Sessions to be created, the SAN Copy Sessions being one example of a snapshot  118 . In another embodiment, the primary storage  114  includes one or more Symmetrix servers. 
   Broadly, primary storage  114  is one of many storage mediums that are commonly employed in the art to store data. Examples include, but are not limited to, disk storage (e.g., optical disks, hard disks, RAIDs, floppy disks, zip disks, and the like), tape storage (e.g., magnetic tape, paper tape), solid state memory devices (e.g., flash memory, EEPROM, and the like), as well as any other storage medium currently known in the art or developed in the future. In embodiments where the primary storage  114  stores data on disk rather than on tape storage, this allows files or entire volumes to be easily surfaced and copied to another location (e.g., a different storage device within primary storage  114  or a different storage network altogether) for performing other functions on the data such as backup/recovery, data mining or data consistency analysis. 
   Turning back to the description of host computer  102  illustrated in  FIG. 1B , the MAGIC platform  106  operates on an operating system  122 . In one embodiment, the operating system  122  is modified so that some of the components are replaced by components of the MAGIC platform. For example, as shown in  FIG. 1B , the operating system  122  could include a MAGIC IP Stack  124  and a MAGIC File system  126 . The operating system  122  can be any operating system known in the art. In one embodiment, the operating system is a Windows® operating system. 
   The operating system  122  boots off of the local hard drive and cannot access the MAGIC platform  106  or production application  104 . In contrast, the MAGIC platform  106  and production application  104  boots off of production volume  116  in the primary storage  114 . Thus, the production volume  116  represents a large amount of data that is unavailable for desirable replication operations. Further, the conventional database management service  110  on MAGIC platform  106  that controls the creation of the production volume  116  and clone volume  117  lacks various desirable replication operations, including, but not limited to, snapshot management, snapshot rotation policies, advanced indexing, high speed parallelism, automated media management, LAN-free backup, cluster awareness, and dynamic tape drive sharing. These and other features would be desirable when performing backup/recovery operations on data for production applications  104  and/or data relating to the MAGIC platform itself. 
   To overcome these deficiencies, as shown in  FIGS. 1A and 1B , proxy host  170  and backup server  152  are provided to perform backup/recovery functions. The proxy host  170  uses the ability of the production volume  116  and clone volume  117  to be temporarily severed from a “normal state” to a “special state” in order to perform other replication functions. After severing has occurred, proxy host  170  directly communicates with primary storage  114  (as shown by the dashed line) to initiate a remote backup/recovery of the clone volume  117  to or from backup storage  154  or to create snapshots  118  of the clone volume  117  in the primary storage  114  at time t n . Thus, in the event that the storage device  115 A crashes, the data is recovered from backup storage  154  and/or snapshots  118 . 
   Snapshots  118  reside on local or remote storage arrays  115 B and can be used for quick recovery and disaster recovery. Using snapshots  118  can result in less downtime compared to other remote backup options, such as tape-based restore, which is one example of how backup storage  154  can be used. In the embodiment of  FIGS. 1A and 1B , snapshots  118  are shown stored on storage device  115 B, which is part of the primary storage  114  but located at a different location than storage device  115 A. Thus, the snapshots  118  located on a different storage device  115  than production volume  116  and clone volume  117  provide an added level of protection for keeping data secure. In one embodiment, the snapshot  118  is a block level copy (i.e., raw data) of a production volume  116  or clone volume  117 . In one embodiment, more than one snapshot  118  is generated at different times from the production volume  116  so that snapshots exist at various points in time. 
   Thus, in one embodiment, the request for creating a backup of clone volume  117 , and/or generating snapshots  118  is generated by backup server  152 , for example, using a jobs daemon  153  residing on backup server  152 . The backup server  152  may further be configured for controlling other backup operations. For example, the backup server  152  may control and direct all automated, server-initiated backup operations or processes, while the proxy host  170  may control ad hoc backup and recover operations. It will be appreciated that the backup server  152  may have additional functionalities not available to the proxy host  170 , such as those listed above. 
   In  FIGS. 1A and 1B , the backup server  152  communicates with backup storage  154  where one or more copies of clone volume  117  can be stored. The backup storage  154  can be located at the backup server  152  or may be distinct and separate from the backup server  152 . The data  156  at backup storage  154  represents one or more copies of the clone volume  117  that has been backed up by the backup server  152  on the backup storage  154 . The data  156  may include data obtained from the primary storage  114 , or may also include other data, such as the data stored on host computer  102 , as well as data from other sources. 
   The backup server  152  may also store and manage a client file index  158  and a media database  160  on the backup server  152  itself and/or on the backup storage  154 . The client file index  158  is an index of the backed up data items. The media database  160  is an index of the backup volumes. The client file index  158  and the media volume  160  will be collectively referred to herein as the online indices  162 . However, it will be appreciated that other operating systems may use similar data structures for maintaining the directories and backed up items in order to restore the directories and items during recovery. While snapshots  118  are only stored in primary storage  114 , the online indices  162  may also store media database entries and file indexes of snapshot copies  118  which can be browsed to facilitate locating snapshot copies  118  in primary storage  114  for recovery or other replication operations. 
   Backup server  152  and proxy host  170  include a graphical user interface  164  that is configured to display source of data (i.e., host computers  102 ) and/or the contents of primary storage  114  in an organized manner, such as by displaying volumes in a hierarchical structure. With regard to displaying the source of data, the graphical user interface  164  can display an identification number for a host computer  102  along with the associated production volumes  116  relating to that host computer. The graphical user interface  164  may also be used to display how one or more host computers  102  are networked together (e.g., network  103 ) to understand how data relating to the one or more host computers is organized in primary storage  114 . In another example, data relating to a single host computer  102  may actually be stored across multiple production volumes  116 , which can be graphically displayed to a user via graphical user interface  164 . Graphical user interface  164  may also allow the user to configure primary storage  114  to ensure that the primary storage has sufficient storage allocated to protect a particular volume, directory, or application. The graphical user interface  164  is configured to allow a user to initiate backup operations for clone volumes  117  and/or generate snapshots  118  and determine where the data will be stored. The graphical user interface  164  is further used during a recovery operation to select one or more backup clone volumes  117  and/or snapshots  118  and to direct how the recovery operation should occur. 
   The backup operations performed by the backup server  152  on the data of host computer  102  are typically performed automatically in accordance with a schedule established by a user. However, a user may initiate ad hoc backup operations directly from the proxy host  170  and/or backup server  152 . Further, recovery operations can be performed from proxy host  170  and/or backup server  152 . 
   As further depicted in  FIGS. 1A and 1B , a proxy host  170  initiates ISB protocol operations such as splitting the production volume  116  and clone volume  117  between “normal state” and “special state” which then enables the proxy host  170  to communicate directly with primary storage  114  (see dashed line) to perform a backup of a clone volume  117  or generate one or more snapshots  118 . While proxy host  170 , backup server  152 , and backup storage  154  are shown as separate hardware devices, in one embodiment, aspects of the proxy host  170 , backup server  152  and/or backup storage  154  can be combined into the same hardware device. 
   In one embodiment, a replication API  132  is installed on the MAGIC platform  106  to allow the proxy host  170  to communicate with the MAGIC platform  106  and access ISB functionalities provided by the database management service  110  in order to perform backup/recovery operations on data related to the MAGIC platform  106 , including the production application  104 . For example, through backup server  152 , a user requests a backup of clone volume  117 , which is relayed to proxy host  170 . Proxy host  170  communicates with replication API  132  to request quiescing or suspending of the subsystems (including production application  104 ) and splitting of production volume  116  and clone volume  117  from normal state to special state in order to accomplish this replication operation. 
   In one embodiment, backup of a clone volume  117  and/or creation of a snapshot  118  occurs while the appropriate protection sets are in an application consistent state. This may be accomplished by quiescing the production application  104  related to the relevant protection sets prior to performing the replication operation. As such, copies of clone volume  117  and/or snapshots  118  that reflect an “application consistent state” allow critical components of the production application  104  and/or MAGIC platform  106  to be backed up and recovered as a consistent unit. Further, a backup of a clone volume  117  and/or snapshot  118  can further be ensured of being in an application consistent state by severing the connection between a production volume  116  and clone volume  117  while performing the replication operation. 
   As previously mentioned, the backup of clone volume  117  and/or snapshots  118  is used to recover data that has been lost during a disaster, as well as for other replication operations such as perform mirroring operations, data mining, data consistency checking, and the like. 
   Exemplary Software Architecture for Proxy Host 
   With reference to  FIG. 2 , a system and/or software architecture  200  is illustrated in further detail, wherein like elements with regard to  FIGS. 1A and 1B  will be referred to with the same reference numeral. System  200  illustrates an exemplary software architecture that operates on backup server  152 , proxy host  170 , and/or host computer  102  in further detail. 
   As shown in  FIG. 2 , proxy host  170  includes an ISB manager configuration  202 . The ISB manager configuration  202  is configured to map one or more production volumes  116  into a logical protection set for a replication operation initiated by proxy host  170 . In one embodiment, the logical protection set may be a grouping  103 . It will be appreciated that the one or more production volumes  116  might all be attached to one host computer  102  ( FIG. 1B ) or portions of the production volumes  116  might be distributed within different host computers  102 A,  102 B,  102 C ( FIG. 1A ). Furthermore, a set of snapshots  118  created at different times can be created for each protection set of production volume(s). 
   Proxy host  170  also includes a job sequencer  204  that coordinates the communications between the various modules in proxy host  170  to perform a replication operation. Resource database manager  206  communicates with the ISB manager configuration  202  to identify production volumes  116  and/or clone volumes  117  related to the replication operation. Host computer manager  208  communicates with the host computer  102  to initiate ISB functions of splitting a production volume  116  and clone volume  117 . Storage services manager  210  communicates with the primary storage  114  to prepare a clone volume  117  for surfacing and mounting. Surfacing a clone volume  117  involves exposing a clone volume  117  on the primary storage  114  so that the proxy host  170  can recognize the clone volume in its directories to allow storage services manager  210  to select the clone volume  117  for replication operations. Mounting involves assigning a drive letter to the surfaced clone volume  117  to allow a user to browse the clone volume  117  for accessing files, directories, etc. 
   Snapshot manager  212  communicates with primary storage  114  to generate snapshots of a clone volume  117 . Backup and recovery manager  214  facilitates backup and recovery operations that involve backup storage  154  or other storage devices that are remote from the production volume  116  and clone volume  117  (e.g., storing a snapshot  118  on a different storage device  115 B than storage device  115 A). 
   Exemplary Replication Operations 
     FIG. 3  illustrates an overview of an exemplary method  300  for performing a backup of data located in the primary storage  114 . At  302 , backup server  152  sends a backup command to proxy host  170 . At  304 , proxy host  170  sends a split command using ISB protocol to host computer  102  to split the production volume  116  and clone volume  117 . At  306 , host computer  102  initiates splitting of the production volume  116  and clone volume  117  to render the production volume and clone volume in a special state. 
   At  308 , proxy host  170  performs a backup of the clone volume  117  to backup storage  154 . Alternatively, at  310 , proxy host  170  generates a snapshot  118  of clone volume  117  and stores the snapshot in a storage device  115 B which can be the same or different storage array as the storage device  115 A. Thus, as used herein, the term “backup” broadly refers to various methods for creating duplicate copies of data stored in production volume  116  at a particular point in time, which exemplarily include copying the clone volume  117  to a remote storage  154  or generating a snapshot  118 . 
   At  312 , the proxy host  170 , using ISB protocol, directs the host computer  102  to return the production volume  116  and clone volume  117  back to their connected, normal state. At  314 , the host computer  102  resynchronizes the data on production volume  116  and clone volume  117 . 
   In further detail,  FIG. 4  illustrates an exemplary method  400  for performing a backup of clone volume  117  to remote storage  154 . At  402 , backup server  152  initiates a backup. This includes backup server  152  passing an initiate backup command to proxy host  170  that includes client settings that identify the name of a group or network  103 . The proxy host  170  looks up the group name using the ISB manager configuration  202  (see  FIG. 2 ) to get the identity of host computers  102  attached to the group  103 . The data structure of the initiate backup command includes the type of backup operation to perform (e.g., backup to remote storage  152  or create snapshot  118 ). 
   At  404 , the proxy host  170  initiates splitting of the production volume and the clone volume related to the group  103 . The proxy host  170  identifies which production volumes  116  and/or host computers  102  are related to the protection set to be backed up. Identifying the production volume  116  includes communicating with ISB manager configuration  202  located on the proxy host  170 . In one embodiment, job sequencer  204  on the proxy host  170  sends a command to resource database manager  206  to obtain the identification of the host computer  102  associated with the backup command. This includes identifying one or more host computers  102  (i.e., a group of host computers) that are associated with the backup operation. The resource database manager  206  communicates with the ISB manager configuration  202  to obtain the information about production volume  116  related to the identified host computers  102 , which includes, but is not limited to, the one or more storage devices  115  located in primary storage  114  (e.g., CLARiiON ID number), the serial number and/or LUN number of the production volume  116 . The job sequencer  204  receives the production volume  116  information from resource database manager  206 . The job sequencer  204  passes the production volume  116  information to the host computer manager  208  to identify which production volume  116 /clone volume  117  to split. A MAGIC coordinator in the host computer manager  208  creates ISB worker threads which are sent to the host computers  102  related to the production volume  116  to identify the production volumes  116  to split. 
   At  406 , the host computer  102  responds with at least one production volume  116  and initiates splitting of the production volume  116  with a clone volume  117 . Thus, in the primary storage  114 , the connection between the production volume  116  and clone volume  117  are temporarily severed into a special state. While the connection is severed, the host computer  102  is still able to perform read/write operations to the production volume  116 . 
   At  408 , after the split is completed, the storage devices  115  containing the production volume  116  and/or clone volume  117  return the identification of the clone volume  117  to the host computer  102 . This includes information that allows the host computer  102  to uniquely identify the location of clone volume  117  within primary storage  114  as well as the MAGIC database/segment name to be backed up. For example, in a CLARiiON system, the identification information for the clone volume  117  can include the CLARiiON ID number of the storage device  115  and the LUN number of the clone volume  117 . 
   At  410 , host computer  102  reports back to the proxy host  170  that the split was successful and provides the identification information of the clone volume  117  and the MAGIC database/segment name to be backed up. This information is received by the MAGIC ISB coordinator on the host computer manager  208 , which allows the host computer manager  208  to create a backup work list of clone volumes  117  that is backed up per a successful split from their respective production volume  116 . The host computer manager  208  sends the backup work list to the job sequencer  204 . 
   The job sequencer  204  prepares to perform a backup of the clone volumes  117  identified in the backup work list. This includes surfacing and mounting the clone volumes as described above. The job sequencer  204  sends a surface and mount command to storage services manager  210 , including the backup work list. The storage services manager  210  accesses the primary storage  114  and maps the clone volumes  117 . This includes accessing index  120  located at primary storage  114 . The storage services manager  210  returns a mount map to the job sequencer  204 . After receiving the mount map, the job sequencer  204  sends a persistent backup command to the backup and recovery manager  214 . The backup and recovery manager  214  has a coordinator that initiates a backup job for each item included on the backup work list. 
   At  412 , backup and recovery manager  214  performs a backup of the clone volume  117  to backup server  152 , which directs saved data to backup storage  154 . Backup and recovery manager  214  communicates with backup server  152  to provide identification information of the clone volume  117  to be copied and saved as well as facilitating the connection between the proxy host  170  and primary storage  114 . 
   At  414 , the proxy host  170  prepares to finalize the ISB backup process. The backup and recovery manager  214  at the proxy host  170  receives the backup report and forwards the report to job sequencer  204 . Job sequencer  204  sends a command to host computer manager  208  to reestablish the connection between the production volume  116  and clone volume  117 , along with the backup report. The MAGIC ISB coordinator in the host computer manager  208  sends a reconnect command to the host computer  102 . 
   At  416 , the host computer  102  sends a request to primary storage  114  to resynchronize the production volume  116  and clone volume  117 . The database management service  110  on the MAGIC platform  106  of the host computer  102  initiates reconnection between the production volume  116  and clone volume  117  back to a normal state and performs synchronization of any new data on the production volume  116  that occurred during the backup operation to the clone volume  117 . 
   At  418 , after synchronization is initiated, the host computer  102  returns the status to the proxy host  170 . This includes sending a report to the host computer manager  208  on the proxy host  170  that the synchronization is underway. 
   At  420 , the proxy host  170  returns the status of the synchronization to the backup server  152 . 
     FIG. 5  illustrates an exemplary method  500  for creating a snapshot  118  of a clone volume  117  located in primary storage  114 . At  502 , backup server  152  initiates a backup. This includes backup server  152  passing an initiate backup command to proxy host  170  that includes client settings that identify the name of a group or network  103 . The proxy host  170  looks up the group name using the ISB manager configuration  202  (see  FIG. 2 ) to get the identity of host computers  102  attached to the group  103 . Thus, the data structure of the initiate backup command includes the type of backup operation to perform (e.g., backup to remote storage  152  or snapshot copy to primary storage  114 ). 
   At  504 , the proxy host  170  initiates splitting of the production volume and the clone volume related to the group  103 . The proxy host  170  identifies which production volumes  116  and/or host computers  102  are related to the protection set to be backed up. Identifying the production volume  116  includes communicating with ISB manager configuration  202  located on the proxy host  170 . In one embodiment, job sequencer  204  on the proxy host  170  sends a command to resource database manager  206  to obtain the identification of the host computer  102  associated with the backup command. This includes identifying one or more host computers  102  (i.e., a group of host computers) that are associated with the backup operation. The resource database manager  206  communicates with the ISB manager configuration  202  to obtain the information about production volumes  116  related to the identified host computers, which includes, but is not limited to, the one or more storage devices  115  located in primary storage  114  (e.g., CLARiiON ID number), the serial number and/or LUN number of the production volume  116 . The job sequencer  204  receives the production volume  116  information from resource database manager  206 . The job sequencer  204  passes the production volume  116  information to the host computer manager  208  to identify which production volume  116 /clone volume  117  to split. A MAGIC IP coordinator in the host computer manager  208  creates ISB worker threads which are sent to the host computers  102  related to the production volume  116  to identify the production volumes  116  to split. 
   At  506 , the host computer  102  responds with at least one production volume  116  and initiates splitting of the production volume  116  with a clone volume  117 . Thus, in the primary storage  114 , the connection between the production volume  116  and clone volume  117  are temporarily severed into a special state. While the connection is severed, the host computer  102  is still able to perform read/write operations to the production volume  116 . 
   At  508 , after the split is completed, the storage devices  115  containing the production volume  116  and/or clone volume  117  return the identification of the clone volume  117  to the host computer  102 . This includes information that allows the host computer  102  to uniquely identify the location of clone volume  117  within primary storage  114  as well as the MAGIC database/segment name to be backed up. For example, in a CLARiiON system, the identification information for the clone volume  117  can include the CLARiiON ID number of the storage device  115  and the LUN number of the clone volume  117 . 
   At  510 , host computer  102  reports back to the proxy host  170  that the split was successful and provides the identification information of the clone volume  117  and the MAGIC database/segment name to be backed up. This information is received by the MAGIC ISB coordinator on the host computer manager  208 , which allows the host computer manager  208  to create a snapshot work list of clone volumes  117  from which one or more snapshots is created based on a successful split from their respective production volume  116 . The host computer manager  208  sends the snapshot work list to the job sequencer  204 . The job sequencer  204  gets Integrated Disaster Recovery (IDR) relationships for the snapshot work list from resource database manager  206 . The IDR relationships map out available snapshot storage spaces and assigns the available snapshot storage spaces to store a copy of the identified clone volumes  117  as a snapshot  118 . The snapshots  118  can be configured as full or incremental copies. Full copy snapshots  118  will have the full copy of the clone volume  117  while incremental copy snapshots  118  will have a full copy of the clone volume  117  and then copy only the changed blocks on subsequent execution. Identification of the snapshots  118  corresponding to the clone volume  117  (or IDR relationships) is required to create the snapshots  118  for each clone volume  117  and prepare the system for disaster recovery and quick recovery with minimal loss of data. 
   Job sequencer  204  sends the IDR sessions identified in the snapshot work list to the snapshot manager  212 . The snapshot manager  212  communicates with the primary storage  114  to identify which IDR sessions are available to ensure that the snapshot storage spaces that were identified at  510  exist and are available and returns the identification of the available IDR sessions to the job sequencer  204 . Proxy host  170  uses the available IDR sessions to select from this list of snapshots  118  one or more IDR sessions to perform. This includes sending the available IDR session list from the job sequencer  204  to the resource database manager  206 . The resource database manager  206  communicates with the ISB Manager configuration  202  to select one or more IDR sessions (i.e., the name of a snapshot  118 , the snapshot storage space to which the snapshot will be saved, and the clone volume(s) from which the snapshot will be copied) to perform and sends these selections to the job sequencer  204  via the resource database manager  206  and this sequence is done iteratively for each clone volume  117  in the work list. 
   At  512 , proxy host  170  creates one or more snapshots from the selected IDR sessions. This includes job sequencer  204  sending a command to snapshot manager  212  to start the selected one or more snapshots and also sends the IDR relations. The snapshot manager  212  communicates with the primary storage  114  to generate the snapshots from the clone volume  117 . In one embodiment, this includes creating a San Copy Session of a clone volume  117 , effectively copying the data from clone volume  117  into the snapshot storage space(s) that was selected. 
   The primary storage  114  reports to the snapshot manager  212  when the snapshots  118  are generated. After the snapshot(s)  118  are created, job sequencer  204  sends a commit IDR session command to the resource database manager  206  which updates the ISB manager configuration  202 . Job sequencer  204  sends a save command to the backup and recovery manager  214  which communicates with the primary storage  114  to save the snapshots to the identified snapshot storage space(s). This includes saving the snapshot on a storage device  115  in the primary storage  114 , saving the snapshot in backup storage  154 , or saving the snapshot to another storage device in a storage cluster of storage devices separate from the primary storage. After the snapshots are saved to an identified snapshot storage space, the proxy host  170  reports to the backup server  152  the location of the snapshots. 
   At  514 , the backup server  152  records details of the snapshot backup process in its online indices  162 . 
   At  516 , the proxy host  170  prepares to finalize the ISB backup process. The backup and recovery manager  214  at the proxy host  170  receives the backup report and forwards the report to job sequencer  204 . Job sequencer  204  sends a command to host computer manager  208  to reestablish the connection between the production volume  116  and clone volume  117  back to a normal state, along with the backup report. The MAGIC ISB coordinator in the host computer manager  208  sends a reconnect command to the host computer  102 . 
   At  518 , the host computer  102  sends a request to primary storage  114  to resynchronize the production volume  116  and clone volume  117 . The database management service  110  on the MAGIC platform  106  of the host computer  102  initiates reconnection between the production volume  116  and clone volume  117  back to a normal state and performs synchronization of any new data on the production volume  116  that occurred during the backup operation to the clone volume  117 . 
   At  520 , after synchronization is initiated, the host computer  102  returns the status to the proxy host  170 . This includes sending a report to the host computer manager  208  on the proxy host  170  that the synchronization is underway. 
   At  522 , the proxy host  170  returns the status of the synchronization to the backup server  152 . 
   Exemplary Recovery Operations 
     FIG. 6  illustrates an exemplary system  600  for performing recovery operations wherein like elements with regard to  FIGS. 1A ,  1 B and/or  2  will be referred to with like reference numerals. As shown in  FIG. 6 , before a recovery operation, a disaster recovery site  602  can be created. A disaster recovery site  602  is necessary where storage device  115 A containing production volume  116  and/or clone volume  117  has for some reason been rendered inoperable. 
   Disaster recovery site  602  includes one or more storage devices  607  including a disaster production volume  604  and one or more recovery volumes  606 A,  606 B,  606 C. The recovery volumes  606  are copies of a clone volume  117 . Alternatively, the recovery volumes  606  are copies of snapshots  118  taken at different points in time. In one embodiment, disaster recovery site  602  is created by backup server  152  accessing data in backup storage  154  and recovering data into one or more recovery volumes  606 . This is referred to as a “pre-restore” period. 
   In one embodiment, an existing proxy host  170  can be used to facilitate recovery of a primary storage. Alternatively, it may be desirable to provide a recovery proxy host  170 ′ in the event that the existing proxy host  170  is unavailable for recovery. Where a recovery proxy host  170 ′ is used, a graphical user interface  603  can be restored or recovered to proxy host  170 ′. Recovery of GUI  603  involves recovery of the resource database manager  206  and ISB Manager configuration  202 . These will be used to browse the client file indexes  158  for the backups of the clone volumes  117  and/or snapshots  118  so that the user knows what information is available for recovery. The graphical user interface  603  allows a user to select the volumes that need to be restored, data to be used to recover the data that was lost, and how the data should be restored. 
   Once the disaster recovery site  602  is established, backup server  152  communicates with proxy host  170 ′, placing the proxy host  170 ′ in communication with the disaster recovery site  602 . As shown in  FIG. 6 , disaster recovery site  602  also includes a host computer  102 ′ and a storage device  115 ′ that can be configured to function analogous to the host computer  102  and storage device  115 A. This allows the proxy host  170 ′ to perform various operations on the pre-restored information in storage device  607  to configure the storage device  115 ′ to hold a production volume  116 ′ and a clone volume  117 ′ that can be operational with a host computer  102 ′, which will be described further below. Backup server  152  then may or may not disconnect from direct communication with the disaster recovery site  602 . In the event that backup server  152  does disconnect from direct communication with the disaster recover site  602 , backup server  152  is able to communicate with the disaster recovery site  602  via proxy host  170 ′. 
     FIG. 7  illustrates an exemplary method  700  for recovering data from a disaster recovery site  602 , wherein the recovered data can be recovered to various locations and in various different ways. At  702 , a recovery volume  606  is pre-restored at disaster recovery site  602 . This includes copying data from a backup of a clone volume  117  from backup storage  154  or one of the snapshots  118  into one of the disaster production volume  604  and/or recovery volumes  606 . Also,  702  includes restoring a graphical user interface  603  on the proxy host  170 ′. 
   As illustrated in  FIG. 7 , in one embodiment, at  704 , a recovery volume  606  from storage device  607  on disaster recovery site  602  is copied to recovery clone volume  117 ′ on recovery storage device  115 ′ of disaster recovery site  602 . Alternatively, at  706 , a recovery volume  606  from storage device  607  is copied to recovery production volume  116 ′ on recovery storage device  115 ′ of the disaster recovery site  602 . In still another embodiment, at  708 , the data from a recovery volume  606  is copied to disaster production volume  604 . 
   Thus, if the user selects copying of recovery volume  606  to disaster production volume  604  ( 708 ), the user can configure the storage device  607  to act as a new primary storage, with the recovery volume  606  acting as a clone volume to the disaster production volume  604 . Alternatively, if the user selects copying of recovery volume to recovery production volume  116 ′ ( 706 ) and recovery clone volume  117 ′ ( 704 ), then the recovery storage device  115 ′ can act as the new primary storage. 
   At  710 , the recovery storage device  115 ′ or  607  (depending on the recovery scenario used) is resynchronized with recovery host computer  102 ′. This can include proxy host  170 ′ connecting the recovery host computer  102 ′ with whichever storage device acts as the new primary storage so that the recovery host computer  102 ′ can proceed to use the new production volume and clone volume to store data from a recovery production application located on the recovery host computer. This can further include connecting the disaster production volume  604  with the recovery/clone volume  606  or, alternatively, connecting the recovery production volume  116 ′ and recovery clone volume  117 ′ using ISB protocol. 
   In summary, the proxy host  170  facilitates communication between the MAGIC platform  106  on the host computer  102  and the backup server  152  making backup and recovery functions that were previously unavailable to the production volume  116  and clone volume  117  now possible. These functions include scheduling backups of clone volume  117  to a backup storage  154 , scheduling creation of snapshots  118  at various points in time. Performing remote recovery of data from the saved clone volumes  117  and/or snapshots  118  is also facilitated by proxy host  170 . In addition, the backup server  152  maintains records of backup/snapshot operations and locations of backup/snapshots in its online indices. 
   Embodiments included dedicated devices or systems that include both hardware and/or software components. Embodiments within the scope of the present invention also include computer readable media having executable instructions or data fields stored thereon. Such computer readable media is any available media which is accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which is used to store the desired executable instructions or data fields and which is accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer readable media. Executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. 
   Those skilled in the art will appreciate that the invention are practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor-based or programmable customer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules are located in both local and remote memory storage devices. 
   The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.