Method and system for insuring data integrity in anticipation of a disaster

A preparation of a storage system of a pending disaster at an onsite location of the storage system involves the storage system receiving a disaster preparation initiation from an offsite client. In response to receiving the disaster preparation initiation from the offsite client, the storage system to executes disaster preparation of onsite data including managing a temporary storage of onsite data volumes to at least one peer site, managing a storage of onsite cached data to a first onsite removable media, and/or managing a storage of onsite management information to a second onsite removable media.

FIELD OF THE INVENTION

The present invention generally relates to a preparation of a storage system in anticipation of a disaster (e.g., a fire, a flood, a hurricane, etc). The present invention specifically relates to a preservation of data responsive to a disaster warning in a manner that insures data integrity in the recovery of the data after the disaster.

BACKGROUND OF THE INVENTION

In hierarchical virtual storage systems, intensively used and frequently accessed data is stored in fast but expensive memory. One example of a fast memory is a direct access storage device (“DASD”). In contrast, less frequently accessed data is stored in less expensive but slower memory. Examples of slower memory are tape drives and disk drive arrays. The goal of the hierarchy is to obtain moderately priced, high-capacity storage while maintaining high-speed access to the stored information.

One such hierarchical storage system is a virtual tape storage system (“VTS”) including a host data interface, a DASD, and a number of tape devices. When the host writes a logical volume, or a file, to the VTS, the data is stored as a file on the DASD. Although the DASD provides quick access to this data, it will eventually reach full capacity and a backup or secondary storage system will be needed. An IBM 3590 tape cartridge is one example of a tape device that could be used as a backup or secondary storage system.

When the DASD fills to a predetermined threshold, the logical volume data for a selected logical volume is then appended onto a tape cartridge, or a physical volume, with the original left on the DASD for possible cache hits. When a DASD file has been appended to a tape cartridge and the original remains on the DASD, the file is “premigrated.”

When the host reads a logical volume from the VTS, a cache hit occurs if the logical volume currently resides on the DASD. If the logical volume is not on the DASD, the storage manager determines which of the physical tape volumes contains the logical volume. The corresponding physical volume is then mounted on one of the tape devices, and the data for the logical volume is transferred back to the DASD from the tape.

From time to time, a warning of a pending disaster may be issued for an onsite location of a storage system like a VTS. For example, an onsite location of a storage system may receive a warning of an approaching high severity hurricane, a warning of a fire growing in nearby areas, or a warning of a potential breach of a levy or a damn. The data storage industry is therefore continually striving to provide clients that are forewarned of a disaster with an ability to protect the data of the storage system in view of having an opportunity of 100% data recovery following the disaster.

SUMMARY OF THE INVENTION

In anticipation of an onsite disaster, a client that has been forewarned of the disaster is provided with an ability to protect the data of the storage system at the onsite location from an offsite location in view of having an opportunity of 100% data recovery following the disaster.

A first form is a computer readable medium embodying a program of machine-readable instructions executable by a processor to perform operations for preparing the storage system of a pending disaster at an onsite location of the storage system. The operations comprise the storage system receiving a disaster preparation initiation from an offsite client, and in response to receiving the disaster preparation initiation from the offsite client, the storage system executing a disaster preparation of onsite data including managing a temporary storage of onsite data volumes to at least one peer site, managing a storage of onsite cached data to a first onsite removable media, and/or managing a storage of onsite management information to a second onsite removable media.

A second form is a storage system comprising a processor, and a memory storing instructions operable with the processor for preparing the storage system for preparing the storage system of a pending disaster at an onsite location of the storage system. The instructions are executed for the storage system receiving a disaster preparation initiation from an offsite client, and in response to receiving the disaster preparation initiation from the offsite client, the storage system executing a disaster preparation of onsite data including managing a temporary storage of onsite data volumes to at least one peer site, managing a storage of onsite cached data to a first onsite removable media, and/or managing a storage of onsite management information to a second onsite removable media.

A third form is a method for preparing a storage system of a pending disaster at an onsite location of the storage system. The method comprises the storage system receiving a disaster preparation initiation from an offsite client, and in response to receiving the disaster preparation initiation from the offsite client, the storage system executing a disaster preparation of onsite data including managing a temporary storage of onsite data volumes to at least one peer site, managing a storage of onsite cached data to a first onsite removable media, and/or managing a storage of onsite management information to a second onsite removable media.

The aforementioned forms and additional forms as well as objects and advantages of the present invention will become further apparent from the following detailed description of the various embodiments read in conjunction with the accompanying drawings. The detailed description and drawings are merely illustrative rather than limiting, the scope of the present invention being defined by the appended claims and equivalents thereof.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1illustrates a storage domain20for serving a pair of hosts10and11. Storage domain20employs four (4) virtual tape server clusters30interconnected by a network80with each cluster30including a virtualization node (“VN”)40and a disk (“DK”)50for emulating a tape drive to hosts10and11. Each cluster30further includes a hierarchical storage node (“HSN”)60for locally moving data between disk50and an automated tape library (“ATL”)70as well as remotely moving data between a local disk50and a remote disk50.

In one exemplarily embodiment, as shown inFIG. 2, disk50serves as a virtual volume cache containing virtual volumes for local and remote access thereto and library70includes a robotic accessor71for mounting physical tapes (“PT”)72in physical tape drives73for access to physical volumes stored in physical tapes72. To this end, virtualization node40employs a pair of tape daemons41and42for operating on virtual volume files residing in either local cache50or a remote cache50as directed by host10or host11, and hierarchical storage node60employs a cluster manager61, a remote file access server62, a data mover63, a physical tape manager64, a cache manager65, a recall manager66, a database67, a management interface68and a media manager69.

Cluster manager61coordinates operations between clusters30via tokens that are stored in each cluster's database67to determine which cluster30has a current copy of data and coordinates copying of data between clusters30. Remote file access server62provides a link to cache50by a remote cluster30. Data mover63controls the actual data transfer operations for copies performed between clusters30and transfers of data between cache50and library70.

Physical tape manager64manages physical tapes72in library70in multiple physical volume pools, controls reclamation, borrows/returns volumes from a scratch pool, and controls movement of physical tapes72between pools. Cache manager65controls a copying of data between cache50to library70and any subsequent removal of a redundant copy of data in cache50, and provides control signals to balance data flow between cache50and other node60components. Recall manager66queues and controls recalls of data into cache50from library70on behalf of virtualization node40and cluster manager61.

Management interface68provides information about VTS cluster30and allows a user control and configuration of cluster30. Media manager69manages the handling of physical tapes72and error recovery, and diagnoses errors and determines if the errors were caused by a physical tape drive73of library70or a physical tape media72to thereby take appropriate action.

Referring toFIG. 1, storage domain20is premised on providing each cluster30with a disaster preparation/recovery module (“DPRM”)90that is structurally constructed with hardware, software, firmware or any combination thereof to implement disaster preparation/recovery principles of storage domain20. In one exemplarily embodiment as shown inFIG. 2, module90is installed within hierarchical storage node60as an executable program that can be called by and executed on the hierarchical storage node60as needed prior to an occurrence of a pending disaster of the onsite location of the corresponding cluster30.

FIG. 3illustrates a flowchart200representative of a disaster preparation/recovery method embodying the inventive principles of storage domain20in the context of a pending disaster of cluster30(1), andFIG. 4illustrates a client110connected to each cluster30via a network100for purposes of facilitating an understanding a description ofFIG. 3.

Referring toFIG. 3, in response to a warning of a pending disaster of cluster30(1), a stage S202of flowchart200encompasses client110initiating a disaster preparation of cluster30(1) as a disaster site. In one exemplarily embodiment of stage S202as shown inFIG. 4, client110accesses a web page WP provided by a web server (not shown) of module90(1) whereby client110selects a “Disaster Ready” button (not shown) of web page WP to thereby initiate a disaster preparation of disaster site30(1) as shown inFIG. 4.

A stage S204of flowchart200encompasses disaster site30(1) managing a temporary storage of onsite data volumes at clusters30(2)-30(4) serving as safe peer sites. In one exemplarily embodiment of stage S204, module90(1) marks the onsite data volumes exclusive to disaster site30(1) with a unique identifier for purposes of distinguishing the marked data volumes from other data volumes within the domain, and participates with modules90(2)-90(4) in a replication of each marked data volume to one of the safe peer sites30(2)-30(4) as shown inFIG. 4.

A stage S206of flowchart200encompasses disaster site30(1) managing a storage of cached data and management information to removable media at disaster site30(1) and safe peer sites30(2)-30(4). In one exemplarily embodiment of stage S206, module90(1) migrates all cached data to onsite removable media at disaster site30(1), writes management information in the form of data location information indicative of the location of each replicated and marked data volume to onsite removable media at disaster site30(1), offloads management information in the form of database content and metadata content to onsite removable media at disaster site30(1), and places the removable media storing management information in an onsite I/O station for purposes of such removable media being removed from disaster site30(1) (e.g., RMR shown inFIG. 4). Optionally, module90(1) participates with one or more modules90(2)-90(4) in a replication of the management information and cached data to one or more of the safe peer sites30(2)-30(4).

Stages S204and S206are performed during a pre-disaster phase of the pending disaster to the maximum extent possible in view of the nature of the pending disaster. For example, in view of a small time window for disaster preparation, stage S204may be omitted or partially executed in view of facilitating an execution of stage S206to the maximum extent possible or conversely, stage S206may be omitted or partially executed in view of facilitating an execution of stage S204to the maximum extent possible.

Stages S208-S212of flowchart200is executed during a post-disaster phase of the pending disaster or threat thereof. Prior to an execution of stages S208-212, hardware at disaster site30(1) is replaced and/or repaired as needed based on any damage sustained by disaster30(1) during the disaster or threat thereof. Furthermore, connections to safe peer sites30(2)-30(4) are also replaced and/or repaired as needed.

Upon the onsite hardware and site connections being fully operational, stage S208encompasses client110initiating a disaster recovery of cluster30(1) as the disaster site. In one exemplarily embodiment of stage S208as shown inFIG. 4, client110accesses a web page WP provided by a web server (not shown) of module90(1) whereby client110selects a “Disaster Recovery” button (not shown) of web page WP to thereby initiate the disaster recovery of disaster site30(1) as shown inFIG. 4

Stage S210encompasses disaster site30(1) managing an importation of the management information as stored on the removed removable media and onsite data volumes as temporarily stored on safe peer sites30(2)-30(4). In one exemplarily embodiment, module90(1) imports onsite removable media placed in the onsite I/O station of disaster site30(1) as shown as RMI inFIG. 4. Furthermore, as needed, module90(1) imports the onsite data volumes via offsite removable media from safe peer sites30(2)-30(4) placed in the onsite I/O station of disaster site30(1) and/or via a replication of the onsite data volumes from safe peer sites30(2)-30(4).

Stage S212encompasses clusters30(2)-30(4) returning to pre-disaster states as related to the management information/data volumes of disaster site30(1). In one exemplary embodiment of stage S212, module90(1) utilizes the management information to ensure all of the data volumes stored on disaster site30(1) pre-disaster are stored on disaster site30(1) post-disaster, and modules90(2)-90(4) removes all marked management information and data volumes of disaster site30(1) from peer sites30(2)-30(4)

In practice, storage domain20does not impose any restrictions or any limitations to the structural configurations of modules90for implementing the disaster preparation/recovery principles of storage domain20as embodied by flowchart200. Nonetheless, to further facilitate an understanding of flowchart200, a description ofFIGS. 5-7illustrate flowcharts220-250is provided herein as an exemplarily representation of an implementation of flowchart200by modules90in view of cluster30(1) receiving a warning of a pending disaster at its onsite location.

Referring toFIGS. 4 and 5, a stage S222of flowchart200encompasses module90(1) remaining in a passive state until a receipt of a disaster preparation initiation from client110. In response thereto, during a stage S224of flowchart200, module90(1) completes all existing I/O with hosts10and11and varies its drives offline.

If module90(1) was not situated in a multi-cluster grid as shown inFIG. 5, then module90(1) would proceed to flowchart230as shown inFIG. 6. A stage S232of flowchart230would encompass module90(1) migrating all cached data to onsite removable media, and a stage S234of flowchart230would encompass module90(1) writing database data and metadata to onsite removable media. Thereafter, during a stage S236of flowchart200, module90(1) would identify all onsite removable media storing management information in the form of the database data and the metadata and place the identified removable media in an onsite I/O station for purposes of facilitating a removal of the management information prior to the disaster.

Referring toFIG. 5, in this example case, module90(1) is in a multi-cluster grid as shown inFIG. 4and would therefore proceed to a flowchart240as shown inFIG. 7. A stage S242of flowchart240encompasses module90(1) failovering all new I/O from hosts10and11to safe peer sites30(2)-30(4), and a stage S244of flowchart240encompasses module90(1) completing all queue copies of cached data. Thereafter, during a stage S246of flowchart240, module90(1) marks each logical volume (e.g., all cached data and all physical volumes) with a unique token for purposes of distinguishing the marked logical volumes from other logical volumes within the storage domain. This marking of logical volumes is accomplished on an exclusive basis to ensure only logical volumes being exclusively stored at disaster site30(1) are replicated to the safe peer sites30(2)-30(4) and on a priority basis to ensure the higher priority logical volumes will be replicated to safe peer sites30(2)-30(4) before any lower priority logical volumes. For the priority basis, a priority of each logical volume may be pre-programmed in disaster site30(1) prior to receiving the disaster preparation initiation or be inclusive of the disaster preparation intimation.

A stage S248of flowchart240encompasses module90(1) informing modules90(2)-90(4) of the disaster preparation of disaster site30(1) including a provision of the which logical volumes are marked. In response thereto, modules90(2)-90(4) proceed from a passive stage S252of flowchart250to replicate all of the marked logical volumes from disaster site30(1) to peer sites30(2)-30(4) on an exclusive basis in view of the copy policy settings of the storage domain. As a result, each marked logical volume will be operationally stored on only one of the safe peer sites30(2)-30(4).

Upon completion of stage S248, module90(1) executes stages S232-S236of flowchart230as previously described herein in connection withFIG. 6. However, in view of being in a multi-cluster grid, stage S234additionally encompasses module90(1) offloading data location information to onsite removable media (i.e., information indicative of the location replicated logical volumes among peer sites30(2)-30(40)) and marking all of the management information for disaster recovery (e.g., the data location information, the database data and the metadata). In response thereto, modules90(2)-90(4) further replicates all of the marked management information of disaster site30(1) during a stage S256of flowchart250. Thereafter, modules90(2)-90(4) may place the offsite removable media storing the marked management information in the offsite I/O stations of safe peer sites30(2)-30(4).

Referring toFIGS. 1-7, those having ordinary skill in the art will appreciate numerous benefits and advantages of the embodiments illustrated inFIGS. 1-7including, but not limited to, a single point activated client tool that allows a client to prepare a storage system for a disaster at its onsite location in a manner that facilitates an expedient recovery on the onsite location to its pre-disaster state. Those having ordinary skill in the art will further appreciate how to apply the inventive principles of embodiments as illustrated inFIGS. 1-7as related to more or less complex storage domains than the storage domain shown inFIG. 1, and to more or less complex storage systems than the virtual tape server system shown inFIG. 2.

Referring toFIGS. 1 and 2, in practice, each cluster30may include a processor and a memory for implementing one or more of its components (not shown for clarity purposes). The term “processor” as used herein is broadly defined as one or more processing units of any type for performing all arithmetic and logical operations and for decoding and executing all instructions related to facilitating an implementation by a cluster of the various methods of the present invention. Additionally, the term “memory” as used herein is broadly defined as encompassing all storage space within clusters30(e.g., computer readable mediums of any type).

Those having ordinary skill in the art may develop other embodiments of the present invention in view of the inventive principles of the present invention described herein. The terms and expression which have been employed in the foregoing specification are used herein as terms of description and not of limitations, and there is no intention in the use of such terms and expressions of excluding equivalents of the features shown and described or portions thereof, it being recognized that the scope of the invention is defined and limited only by the claims which follow.